[
https://issues.apache.org/jira/browse/CALCITE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16624568#comment-16624568
]
Vladimir Sitnikov commented on CALCITE-2582:
--------------------------------------------
{quote}As a general comment regarding this rule, I don't see clearly the
benefit of having a copy option{quote}
[~zabetak], copy is here to "keep traits" on the generated RelNodes.
{quote} One that comes to my mind is the case where the newCondition is
simplified to always false where the RelBuilder will not return a Filter but an
empty LogicalValues operator{quote}
That is perfectly fine. The contract for rules in Calcite is "the rule must
keep row type intact, and the new RelNode must yield the same result".
What bothers me is
1) My variation did not compare {{filter.getTraitSet()}}, so I'm
2) It is hard to predict what the result of {{.build()}} would be.
Consider Filter1(Project1(Filter2(...))). Suppose FilterProjectTransposeRule
is called, and it tries to swap Filter1 and Project1.
Then relbuilder is called as: {{.push(filter2).filter(filter1).build()}} and
RelBuilder might easily merge nested filters.
So for now I'm inclined to just adding RexSimplify to the rule, however it
makes sense to make it in line with RelBuilder one:
{code:java} final RexExecutor executor =
Util.first(context.unwrap(RexExecutor.class), // <-- this one is
missing in PR#847
Util.first(cluster.getPlanner().getExecutor(), RexUtil.EXECUTOR));
{code}
{quote} If somebody wants to create specific subclasses of Filter and Project
when applying the rule it suffices to provide an appropriate
RelBuilderFactory{quote}
org.apache.calcite.rel.rules.FilterProjectTransposeRule#INSTANCE is a generic
rule, and it suits all kinds of Filters and Projects thanks to {{copy}}
parameters.
If we drop {{copy}} parameter, then we would have to create lots of
{{FilterProjectTransposeRule}} instances that differ in factories only. The
idea of having {{EnumerableFilterProjectTransposeRule}},
{{DruidFilterProjectTransposeRule}}, etc, etc does not sound right.
> 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)
