[
https://issues.apache.org/jira/browse/CALCITE-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661867#comment-16661867
]
Yuzhao Chen commented on CALCITE-2638:
--------------------------------------
Hi, [~julianhyde]
I have test rand() also, and this bug still exists:
For query:
{code:java}
select sal, r from (select sal, rand() as r from emp) where r > 0.5{code}
The initial plan would be:
{code:java}
LogicalProject(SAL=[$0], R=[$1])
LogicalFilter(condition=[>($1, 0.5)])
LogicalProject(SAL=[$5], R=[RAND()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
While without this patch, the plan will be reduced to:
{code:java}
LogicalProject(SAL=[$0], R=[2.665041719765362E-1])
LogicalProject(SAL=[$5], R=[RAND()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
After applying this patch, the plan is still the same as initial:
{code:java}
LogicalProject(SAL=[$0], R=[$1])
LogicalFilter(condition=[>($1, 0.5)])
LogicalProject(SAL=[$5], R=[RAND()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> Should not do constant reduction when dynamic function is as inputRef in
> project
> --------------------------------------------------------------------------------
>
> 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)
