[
https://issues.apache.org/jira/browse/CALCITE-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Quesada Lopez updated CALCITE-2865:
-----------------------------------------
Description:
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?).
As suggested by [~zabetak], another possibility to reproduce this issue is with
the following test
was:
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?).
> 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
> Assignee: 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?).
> As suggested by [~zabetak], another possibility to reproduce this issue is
> with the following test
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
