[jira] [Commented] (HIVE-8313) Optimize evaluation for ExprNodeConstantEvaluator and ExprNodeNullEvaluator

["Mithun Radhakrishnan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153741#comment-14153741 ] 

Mithun Radhakrishnan commented on HIVE-8313:
--------------------------------------------

This seems to have to do with the changes introduced in HIVE-4209, to provide caching for evaluation of deterministic sub-expressions.

In this particular case, the problem occurs in {{ExprNodeGenericFuncEvaluator::_evaluate()}}:

{code:title=ExprNodeGenericFuncEvaluator.java|borderStyle=solid}
  @Override
  protected Object _evaluate(Object row, int version) throws HiveException {
    rowObject = row;
    if (ObjectInspectorUtils.isConstantObjectInspector(outputOI) &&
        isDeterministic()) {
      // The output of this UDF is constant, so don't even bother evaluating.
      return ((ConstantObjectInspector)outputOI).getWritableConstantValue();
    }
    for (int i = 0; i < deferredChildren.length; i++) {
      deferredChildren[i].prepare(version);
    }
    return genericUDF.evaluate(deferredChildren);
  }
{code}

In Hive 0.10, the {{deferredChildren[i].evaluate()}} would be skipped in its entirety, for "non-eager" evaluation. In Hive 0.12, that condition is checked within the {{prepare()}} function, on every invocation, for *each record*, with explosive effect.

A lot of this cost can be saved by skipping prepare() for {{ExprNodeEvaluator}}s which yield the same value regardless of the row. E.g. {{ExprNodeConstantEvaluator}} and {{ExprNodeNullEvaluator}}. I'll post a patch for this shortly.

> Optimize evaluation for ExprNodeConstantEvaluator and ExprNodeNullEvaluator
> ---------------------------------------------------------------------------
>
>                 Key: HIVE-8313
>                 URL: https://issues.apache.org/jira/browse/HIVE-8313
>             Project: Hive
>          Issue Type: Bug
>          Components: Query Processor
>    Affects Versions: 0.12.0, 0.13.0, 0.14.0
>            Reporter: Mithun Radhakrishnan
>            Assignee: Mithun Radhakrishnan
>
> Consider the following query:
> {code}
> SELECT foo, bar, goo, id
> FROM myTable
> WHERE id IN { 'A', 'B', 'C', 'D', ... , 'ZZZZZZ' };
> {code}
> One finds that when the IN clause has several thousand elements (and the table has several million rows), the query above takes orders-of-magnitude longer to run on Hive 0.12 than say Hive 0.10.
> I have a possibly incomplete fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)