[jira] [Updated] (CALCITE-2638) Constant reducer must not duplicate calls to non-deterministic functions

["Julian Hyde (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde updated CALCITE-2638:
---------------------------------
    Summary: Constant reducer must not duplicate calls to non-deterministic functions  (was: Should not do constant reduction when RexInputRef is a call to a non-deterministic function)

> Constant reducer must not duplicate calls to non-deterministic functions
> ------------------------------------------------------------------------
>
>                 Key: CALCITE-2638
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2638
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Yuzhao Chen
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.18.0
>
>
> When we have a dynamic function like
> {code:java}
> current_timestamp
> {code}
> in the query, calcite will skip constant reduction, for example, for query1: 
> {code:java}
> select sal, current_timestamp as t from emp{code}
> The plan after rule `ReduceExpressionsRule.PROJECT_INSTANCE` is
> {code:java}
> LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> This is as expect cause there is such code snippet in `ReducibleExprLocator#visitCall`:
> {code:java}
> // Even if all operands are constant, the call itself may
> // be non-deterministic.
> if (!call.getOperator().isDeterministic()) {   
>   callConstancy = Constancy.NON_CONSTANT;
> } else if (call.getOperator().isDynamicFunction()){   
>   // We can reduce the call to a constant, but we can't   
>   // cache the plan if the function is dynamic.   
>   // For now, treat it same as non-deterministic.   
>   callConstancy = Constancy.NON_CONSTANT; 
> }{code}
> But for query2:
> {code:java}
> select sal, sal + 5, t from (select sal, current_timestamp as t from emp) {code}
> we will get a plan with rule `ReduceExpressionsRule.PROJECT_INSTANCE` as:
> {code:java}
> + plan before
> LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[$1])
>   LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> + plan after
> LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[CURRENT_TIMESTAMP])
>   LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> This is actually wrong cause `current_timestamp` is dynamic and we do not want to compute it again in the outer project.
> The reason we did constant reduction is that: for query2, we will get a pulled up predicates with tool function `RexUtil.isConstant`, this function decide if the call is constant by invoking `SqlOperator#isDeterministic` which is default true here. It did not do the `isDynamicFunction()` decision just like `ReducibleExprLocator` and the reduction finally happened which handle by `RexExecutor`.
> Personally i think we should keep sync in reduction logic for `inputRef` and `RexCall` and i reuse the `analyzeCall` and apply a patch here.
> [pull-request](https://github.com/apache/calcite/pull/892)
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)