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)
