[
https://issues.apache.org/jira/browse/CALCITE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623925#comment-16623925
]
Julian Hyde commented on CALCITE-2582:
--------------------------------------
Yeah, this is an old problem: how to add to {{RelBuilder}} the functionality to
replace the many {{RelNode#copy}} methods. I've been thinking about it for a
long time. (For example, I took a stab at it last year with CALCITE-2064. I may
go back to that, because it would be useful for a Convention to know all of its
factories, but it doesn't solve the immediate problem.)
I think this solves the problem elegantly:
{code:java}
final Project project = ...;
final RexNode newCondition = ...;
final RelNode newProject =
relBuilder.push(project.getInput())
.copying(filter, relBuilder -> relBuilder.filter(newCondition))
.copying(project, relBuilder ->
relBuilder.project(project.getProjects(),
project.getRowType().getFieldNames()))
.build();
{code}
The magic happens in the new {{RelBuilder.copying}} method. It creates a
temporary new {{RelBuilder}} that uses a factory to match the {{RelNode}}
argument (e.g. if passed in an EnumerableFilter it replace its
{{filterFactory}} member with {{EnumerableFilter::create}}), and shares the
stack, and with that temporary {{RelBuilder}} calls the supplied call-back.
Here it is:
{code:java}
class RelBuilder {
...
public <R> R copying(RelNode r, Function<RelBuilder, R> action) {
final RelBuilder relBuilder =
new RelBuilder(Contexts.of(r.getFactory(), cluster, relOptSchema,
stack);
return action.apply(relBuilder);
}
}
{code}
We also need a new method {{RelNode.getFactory()}}.
My approach is more elegant because it puts the wisdom of creating {{RelNode}}
instances back into the hands of {{RelBuilder}}, where it should be. It also
means that we can obsolete the huge numbers of overloaded {{RelNode#copy}}
methods. The only thing left to the {{RelNode}} is to tell {{RelBuilder}} what
sub-class of {{Filter}} or {{Project}} it should create when asked, and that is
as it should be.
> 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)
