You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Quesada Lopez (JIRA)" <ji...@apache.org> on 2019/02/25 09:58:00 UTC

[jira] [Created] (CALCITE-2865) FilterProjectTransposeRule generates different traitSet depending on copyFilter / copyProject flags

Ruben Quesada Lopez created CALCITE-2865:
--------------------------------------------

             Summary: FilterProjectTransposeRule generates different traitSet depending on copyFilter / copyProject flags
                 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


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)