[
https://issues.apache.org/jira/browse/CALCITE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625716#comment-16625716
]
Vladimir Sitnikov commented on CALCITE-2582:
--------------------------------------------
Now I'm puzzled if it is acceptable to transpose Filter and Project that have
different conventions at all.
I'm not even sure that we can safely transpose Filter and Project when they
have the same convention.
Consider JdbcProject and JdbcFilter. It might happen that JdbcProject knows how
to fetch data from JDBC, and jdbcFilter knows how to filter the data. It might
happen that JdbcFilter has no way to fetch data from JDBC (== JdbcProject might
have to be the "leaf" relation).
Am I right?
Then we should remove copy parameters and just use the provided relBuilder (==
build Logical relations by default)
> 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)
