[ 
https://issues.apache.org/jira/browse/CALCITE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625941#comment-16625941
 ] 

Stamatis Zampetakis commented on CALCITE-2582:
----------------------------------------------

{quote} Anyway, you are right that the code may not stay for long like that so 
I will commit now the proposed change regarding the RexExecutor.
{quote}
The change is committed so you can have a look if you like!
  
 Regarding the correctness of the rule in general, I think the discussion can 
be quite open. Below, I outline some quick thoughts but I think it would be 
better to open the discussion in the dev list if necessary.

The Filter/Project transformation rules are rather straightforward as far as it 
concerns relational algebra (thus logical operators). When we start bringing 
physical operators in the discussion (as the examples you mentioned) nothing 
can be taken for granted. In that sense, FilterProjectTransposeRule#INSTANCE 
cannot handle all possible kinds of Filter and Project operators so we could 
say it is wrong. On the other hand, if the optimizer that is using the rule 
relies only on certain kind of operators then we could say that the rule is 
correct. Note, that the same correctness issue can be raised for many other 
rules that exist in the framework.

> 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)

Reply via email to