[
https://issues.apache.org/jira/browse/CALCITE-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033044#comment-18033044
]
TJ Banghart commented on CALCITE-7248:
--------------------------------------
One way to do this in {{RelOptRulesTest}} is to set
{{setNoneConventionHasInfiniteCost(false)}} on the VolcanoPlanner and don't add
any of the enumerable converter rules.
We also need to prevent the trait set replacement in {{RelOptFixture}} so the
planner doesn't try to enforce an enumerable convention
[https://github.com/apache/calcite/blob/95350ed1a449bbb2f008fcf2b704544e7d95c410/testkit/src/main/java/org/apache/calcite/test/RelOptFixture.java#L376-L378]
It might make sense to change this to check
{{!planner.getNoneConventionHasInfiniteCost())}} before replacing the trait set
there.
Making this easy for both quidem and {{RelOptRulesTest}} would be great!
> Support the ability to view the logical plan before it enters the Volcano
> Planner
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-7248
> URL: https://issues.apache.org/jira/browse/CALCITE-7248
> Project: Calcite
> Issue Type: Improvement
> Reporter: weihua zhang
> Priority: Major
>
> Currently, in QuidemTest, only plans similar to the following can be viewed:
> {code:java}
> EnumerableUnion(all=[false])
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[CAST($t3):INTEGER],
> expr#9=[12], expr#10=[=($t8, $t9)], MGR=[$t3], COMM=[$t6], $condition=[$t10])
> EnumerableTableScan(table=[[scott, EMP]])
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[CAST($t6):DECIMAL(12, 2)],
> expr#9=[5.00:DECIMAL(12, 2)], expr#10=[>($t8, $t9)], MGR=[$t3], COMM=[$t6],
> $condition=[$t10])
> EnumerableTableScan(table=[[scott, EMP]])
> !plan
> {code}
> This is very inconvenient for scenarios where one wants to verify the logical
> plan.It would be great if there was a mechanism that could display the
> logical plan after optimizations such as SubQueryRemoveRule, RelDecorrelator,
> and various RBO (Rule-Based Optimization) processes, with an effect similar
> to the following:
> {code:java}
> LogicalProject(DEPTNO=[$1], V=[OR(AND(IS TRUE(<($1, $3)), IS NOT TRUE(OR(IS
> NULL($6), =($4, 0)))), AND(IS TRUE(>($4, $5)), null, IS NOT TRUE(OR(IS
> NULL($6), =($4, 0))), IS NOT TRUE(<($1, $3))), AND(<($1, $3), IS NOT
> TRUE(OR(IS NULL($6), =($4, 0))), IS NOT TRUE(<($1, $3)), IS NOT TRUE(>($4,
> $5))))]), id = 1681
> LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $2)], joinType=[left]), id
> = 1679
> LogicalProject(ename=[$1], deptno=[$8]), id = 1661
> LogicalTableScan(table=[[scott, emp]]), id = 1590
> LogicalProject(ename=[$0], m=[$2], c=[CASE(IS NOT NULL($3), $3, 0)],
> d=[CASE(IS NOT NULL($4), $4, 0)], trueLiteral=[$5]), id = 1677
> LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $1)], joinType=[left]),
> id = 1675
> LogicalAggregate(group=[{0}]), id = 1666
> LogicalProject(ename=[$1]), id = 1664
> LogicalTableScan(table=[[scott, emp]]), id = 1590
> LogicalAggregate(group=[{0}], m=[MAX($1)], c=[COUNT()],
> d=[COUNT($1)], trueLiteral=[LITERAL_AGG(true)]), id = 1673
> LogicalProject(ename=[$1], DEPTNO=[$8]), id = 1671
> LogicalFilter(condition=[IS NOT NULL($1)]), id = 1669
> LogicalTableScan(table=[[scott, emp]]), id = 1590
> !logicalPlan
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
