[
https://issues.apache.org/jira/browse/CALCITE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
TJ Banghart updated CALCITE-7265:
---------------------------------
Description:
{{RelOptFixture.relFn}} is incompatible with {{withVolcanoPlanner}}
Take a simple existing test case that uses `relFn` to set a test fixture, and
modify it to use a VolcanoPlanner instead of the default HepPlanner:
{code:java}
@Test void testFilterSortTransposeOffset() {
final Function<RelBuilder, RelNode> relFn = b -> b
.scan("EMP")
.project(b.field(0))
.sortLimit(1, 0, b.field(0))
.filter(b.lessThan(b.field(0), b.literal(10)))
.build();
relFn(relFn)
.withVolcanoPlanner(false, p -> {
p.addRule(CoreRules.FILTER_SORT_TRANSPOSE);
})
.checkUnchanged();
}{code}
Throws the following:
{code:java}
Relational expression
rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
to a different planner than is currently being used.
java.lang.AssertionError: Relational expression
rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
to a different planner than is currently being used.
at
org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1266)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:600)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:615)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraits(VolcanoPlanner.java:500)
...{code}
I believe this is because a new planner is created during {{check()}} and
{{checkUnchanged()}}:
See
[CalcitePrepareImp#performl|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L972-L975].
This makes it difficult to test plans with the VolcanoPlanner that do not have
a SQL representation.
was:
{{RelOptFixture.relFn}} is incompatible with {{withVolcanoPlanner}}
Take a simple existing test case that uses `relFn` to set a test fixture, and
modify it to use a VolcanoPlanner instead of the default HepPlanner:
{code:java}
@Test void testFilterSortTransposeOffset() {
final Function<RelBuilder, RelNode> relFn = b -> b
.scan("EMP")
.project(b.field(0))
.sortLimit(1, 0, b.field(0))
.filter(b.lessThan(b.field(0), b.literal(10)))
.build();
relFn(relFn)
.withVolcanoPlanner(false, p -> {
p.addRule(CoreRules.FILTER_SORT_TRANSPOSE);
})
.checkUnchanged();
}{code}
{code:java}
Throws the following:
Relational expression
rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
to a different planner than is currently being used.
java.lang.AssertionError: Relational expression
rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
to a different planner than is currently being used.
at
org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1266)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:600)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:615)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraits(VolcanoPlanner.java:500)
...{code}
I believe this is because a new planner is created during {{check()}} and
{{checkUnchanged()}}:
See
[CalcitePrepareImp#performl|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L972-L975].
This makes it difficult to test plans with the VolcanoPlanner that do not have
a SQL representation.
> RelOptFixture#relFn cannot be used with VolcanoPlanner
> ------------------------------------------------------
>
> Key: CALCITE-7265
> URL: https://issues.apache.org/jira/browse/CALCITE-7265
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.41.0
> Reporter: TJ Banghart
> Priority: Minor
>
> {{RelOptFixture.relFn}} is incompatible with {{withVolcanoPlanner}}
> Take a simple existing test case that uses `relFn` to set a test fixture, and
> modify it to use a VolcanoPlanner instead of the default HepPlanner:
> {code:java}
> @Test void testFilterSortTransposeOffset() {
> final Function<RelBuilder, RelNode> relFn = b -> b
> .scan("EMP")
> .project(b.field(0))
> .sortLimit(1, 0, b.field(0))
> .filter(b.lessThan(b.field(0), b.literal(10)))
> .build();
> relFn(relFn)
> .withVolcanoPlanner(false, p -> {
> p.addRule(CoreRules.FILTER_SORT_TRANSPOSE);
> })
> .checkUnchanged();
> }{code}
> Throws the following:
> {code:java}
> Relational expression
> rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
> to a different planner than is currently being used.
> java.lang.AssertionError: Relational expression
> rel#3:LogicalFilter.NONE.[0](input=LogicalSort#2,condition=<($0, 10)) belongs
> to a different planner than is currently being used.
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1266)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:600)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:615)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraits(VolcanoPlanner.java:500)
> ...{code}
> I believe this is because a new planner is created during {{check()}} and
> {{checkUnchanged()}}:
> See
> [CalcitePrepareImp#performl|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L972-L975].
> This makes it difficult to test plans with the VolcanoPlanner that do not
> have a SQL representation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
