[
https://issues.apache.org/jira/browse/CALCITE-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17604724#comment-17604724
]
Stamatis Zampetakis commented on CALCITE-5285:
----------------------------------------------
bq. This makes the output calc equals to input one which breaks the rest of
query optimizing.
bq.
Can you elaborate what exactly is broken by transforming to the same relation?
Please add some tests in the PR to demonstrate the problem and also ensure that
your solutions fixes it.
> CalcReduceExpressionsRule may transform to same rel
> ---------------------------------------------------
>
> Key: CALCITE-5285
> URL: https://issues.apache.org/jira/browse/CALCITE-5285
> Project: Calcite
> Issue Type: Bug
> Components: server
> Reporter: Krzysztof Ślusarski
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Method {{CalcReduceExpressionsRule#onMatch}} enters the branch and calculates
> {{reduceExpressions()}} condition. If that one is true it creates new calc.
> Unfortunately logic in {{reduceExpressions()}} is different then in the rest
> of the method and it can create a calc that is equal to the input.
> Example query {{{}SELECT floor(this / 1) FROM test{}}}.
> Input calc contains program with exprs:
> {{0 = \{RexInputRef@11348} "$0"}}
> {{1 = \{RexInputRef@11349} "$1"}}
> {{2 = \{RexCall@11350} "CAST($t1):BIGINT(32)"}}
> {{3 = \{RexLiteral@11351} "1:BIGINT(32)"}}
> {{4 = \{RexCall@11352} "/($t2, $t3)"}}
> {{5 = \{RexCall@11353} "FLOOR($t4)"}}
> The one on index 4 can be simplified (the division can be removed). That
> condition is met in {{{}reduceExpressions(){}}}, but following logic in
> {{onMatch()}} doesn't simplify that expression.
> This makes the output calc equals to input one which breaks the rest of query
> optimizing.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
