[jira] [Commented] (IMPALA-15517) Codegen'd AND/OR evaluate both operands, so queries with failing functions depend on codegen

["Zoltán Borók-Nagy (Jira)" <ji...@apache.org>]

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

Zoltán Borók-Nagy commented on IMPALA-15517:
--------------------------------------------

[~hevelebalazs] are you interested in this?

> Codegen'd AND/OR evaluate both operands, so queries with failing functions depend on codegen
> --------------------------------------------------------------------------------------------
>
>                 Key: IMPALA-15517
>                 URL: https://issues.apache.org/jira/browse/IMPALA-15517
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Backend
>            Reporter: Zoltán Borók-Nagy
>            Priority: Major
>              Labels: codegen, ramp-up
>
> The interpreted AndPredicate / OrPredicate short-circuit: the right operand is not
> evaluated if the left one already decides the result. The codegen'd CompoundPredicate
> (compound-predicates.cc) calls both operands unconditionally and combines their results.
> For functions that can raise an error, the result of a query therefore depends on whether
> codegen is enabled.
> Repro on master:
> {code:sql}
> SELECT count(*) FROM functional_parquet.alltypes
> WHERE bool_col OR (int_col = 1000
>     AND CAST(int_col + 100 AS DECIMAL(38,0)) * CAST(1e37 AS DECIMAL(38,0)) > 0);
> {code}
> * with DISABLE_CODEGEN=true: returns 3650
> * with the default options: fails with "UDF ERROR: Decimal expression overflowed"
> 'int_col = 1000' is false for every row, so the multiplication is never needed.
> Only nested AND/OR are affected. Top-level conjuncts are separate expressions, and
> EvalConjuncts() stops at the first false one with codegen too.
> Since codegen can be disabled by the planner (e.g. DISABLE_CODEGEN_ROWS_THRESHOLD), the same
> query can succeed on a small table and fail on a large one. Affected are the functions that
> call FunctionContext::SetError(), e.g. DECIMAL overflow with DECIMAL_V2, and the strict
> variant_get() once expressions on VARIANT are codegen'd (IMPALA-15141).
> Suggested fix: generate short-circuit control flow in CompoundPredicate codegen: evaluate the
> left operand, return early if it decides the result (false for AND, true for OR), and only
> call the right operand otherwise. The performance impact should be measured.
> Workaround: CASE and IF() evaluate their branches lazily with codegen as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org