[
https://issues.apache.org/jira/browse/CALCITE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16624177#comment-16624177
]
Julian Hyde commented on CALCITE-2582:
--------------------------------------
I don't see a huge urgency to this issue; if it takes until after 1.18 to get
this right, so be it. I have wanted to get RelNode.copy into RelBuilder for a
long time, and I think my solution is the right one.
We won't obsolete the RelNode.copy methods as part of this change. You are
right that some uses of it will remain (especially uses that treat RelNodes
generically, e.g. copying into and out of a planner). But the existing
RelNode.copy methods have many problems (e.g. I fear many of them do not set up
traits correctly, or validate expressions if the input types have changed
nullability). So I would want to migrate as much code as possible off of
RelNode.copy early next release.
> FilterProjectTransposeRule does not always simplify the new filter condition
> ----------------------------------------------------------------------------
>
> Key: CALCITE-2582
> URL: https://issues.apache.org/jira/browse/CALCITE-2582
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.17.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Minor
> Fix For: 1.18.0
>
>
> After pushing the filter below the project a new condition is going to be
> generated along with a new Filter operator. The new condition is not going to
> be simplified if the filter operator is copied and not created using the
> RelBuilder.
> Thus the resulting plan may contain redundant conditions which can have a
> slight impact on performance. Apart, from that tests verifying the resulting
> (logical/physical) plan may produce indeterministic results if the rule is
> applied with (a different order and in combination with other rules).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
