[
https://issues.apache.org/jira/browse/CALCITE-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15168150#comment-15168150
]
Julian Hyde commented on CALCITE-1100:
--------------------------------------
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/eaa84951. Thanks
for the PR, [~seanhychu]!
I agree we're OK without a test case. I refactored your code a bit, converting
your 'for' loop with pair-wise comparisons into 'equals' on two lists of
strings.
> If ReduceExpressionsRule generates the same plan, the original plan stops
> triggering other rules
> ------------------------------------------------------------------------------------------------
>
> Key: CALCITE-1100
> URL: https://issues.apache.org/jira/browse/CALCITE-1100
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Sean Hsuan-Yi Chu
> Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Calcite allows users to implement a customized RelOptPlanner#Executor to
> determine how a RexNode is reduced to another.
> In some cases, the customized RelOptPlanner#Executor might decide not to do
> any reduction for a given RexNode (i.e., constExps2 and reducedValues are the
> same in [1]).
> However, for these cases, Calcite is not aware of the {color:red}new plan is
> equivalent to the old one{color}, but just go ahead to force the
> {color:red}Importance{color} of the old/new plan as ZERO [2]. After the
> {color:red}Importance{color} becomes ZERO, the original plan stops triggering
> other rules
> [1] github code:
> https://github.com/apache/calcite/blob/f55d10c147746d6299fb713adc184576380a1f49/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L508
> [2] github code:
> https://github.com/apache/calcite/blob/f55d10c147746d6299fb713adc184576380a1f49/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L184
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
