[jira] [Commented] (CALCITE-2865) FilterProjectTransposeRule generates wrong traitSet when copyFilter/Project is true

["Stamatis Zampetakis (JIRA)" <ji...@apache.org>]

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

Stamatis Zampetakis commented on CALCITE-2865:
----------------------------------------------

Wouldn't be better to demonstrate the problem using HepPlanner and only FilterProjectTransposeRule with a test in RelOptRulesTest? The test should explicitly assert the traitSet. 

> FilterProjectTransposeRule generates wrong traitSet when copyFilter/Project is true
> -----------------------------------------------------------------------------------
>
>                 Key: CALCITE-2865
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2865
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.18.0
>            Reporter: Ruben Quesada Lopez
>            Priority: Major
>
> Problem can be reproduced with the following test:
> {code}
> @Test public void testFilterProjectTransposeRule() {
>   CalciteAssert.that()
>         .withSchema("s", new ReflectiveSchema(new JdbcTest.HrSchema()))
>         .query("?")
>         .withRel(b -> b
>                 .scan("s", "emps")
>                 .filter(b.equals(b.field(1), b.literal(10))) // deptno = 10
>                 .sort(-4) // salary desc
>                 .project(b.field(3)) // salary (**)
>                 .filter(b.equals(b.field(0), b.literal(11500))) // salary = 11500 (**)
>                 .build())
>         .returnsOrdered("salary=11500.0");
> }
> {code}
> If we run the test with a break point at the end of {{FilterProjectTransposeRule#onMatch}} method, we can see that, when the project and filter tagged with (**) are transposed, the generated output (newFilterRel) is different in terms of traitSet, depending if the copyFilter / copyProject flags are used or not:
> - copyFilter and copyProject TRUE (default)
> {code}
> LogicalProject.NONE.[0 DESC]
>     LogicalFilter.NONE.[0 DESC]  // !!!
>         LogicalSort.NONE.[1 DESC]
> {code}
> - copyFilter and copyProject FALSE
> {code}
> LogicalProject.NONE.[0 DESC]
>     LogicalFilter.NONE.[1 DESC]  // !!!
>         LogicalSort.NONE.[1 DESC]
> {code}
> As I see it, the default behavior seems wrong in terms of new filter's traitSet, although the test run successfully (maybe because other rules intervene to build the final plan?).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)