[
https://issues.apache.org/jira/browse/CALCITE-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986395#comment-17986395
]
juntaozhang commented on CALCITE-6899:
--------------------------------------
[~jensen] [~dongsl] Your suggestion is valuable, letting HepPlanner handle
logical plan rewriting and VolcanoPlanner focus on cost-based optimization. As
far as I know, many platforms like Apache Flink do use this approach, which is
indeed effective.
However, if my understanding is correct, this Jira merely points out that
VolcanoPlanner has obvious flaws when applying rules such as
SortRemoveConstantKeysRule and SubQueryRemoveRule. Fixing this bug within the
scope of this Jira, as the two planners currently support all rules and also
permit individual usage.
Therefore, I suggest we proceed with further optimization step by step. Shall
we discuss this via email or make another ticket (similar to CALCITE-6925, the
topic is clear) to seek broader input and then take action accordingly?
> Mismatch of Trait information results in a missing conversion exception
> -----------------------------------------------------------------------
>
> Key: CALCITE-6899
> URL: https://issues.apache.org/jira/browse/CALCITE-6899
> Project: Calcite
> Issue Type: Bug
> Reporter: xiong duan
> Priority: Major
> Labels: pull-request-available
>
> The unit test in RelOptRulesTest：
> {code:java}
> @Test void testEnumerableFilterRule() {
> final String sql = "select ename from emp where sal > all (select comm from
> emp)";
> sql(sql)
> .withVolcanoPlanner(false, p -> {
> p.addRelTraitDef(RelDistributionTraitDef.INSTANCE);
> p.addRule(CoreRules.FILTER_SUB_QUERY_TO_CORRELATE);
> p.addRule(EnumerableRules.ENUMERABLE_FILTER_RULE);
> p.addRule(EnumerableRules.ENUMERABLE_PROJECT_RULE);
> p.addRule(EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE);
> p.addRule(EnumerableRules.ENUMERABLE_JOIN_RULE);
> p.addRule(EnumerableRules.ENUMERABLE_AGGREGATE_RULE);
> }).check();
> } {code}
> It throws an exception:
> {code:java}
> There are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, dist=any.
> Missing conversion is LogicalFilter[convention: NONE -> ENUMERABLE]
> There is 1 empty subset: rel#39:RelSubset#1.ENUMERABLE.broadcast, the
> relevant part of the original plan is as follows
> 14:LogicalFilter(condition=[NOT(<= SOME($5, {
> LogicalProject(COMM=[$6])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> }))])
> 8:LogicalTableScan(subset=[rel#13:RelSubset#0.NONE.any], table=[[CATALOG,
> SALES, EMP]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
