[
https://issues.apache.org/jira/browse/CALCITE-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986303#comment-17986303
]
Silun Dong commented on CALCITE-6899:
-------------------------------------
In my opinion, perhaps we need to consider solving two problems:
1.Unify the behavior of Logical operators on physical properties. If Logical
operators are allowed to have physical properties, then all Logical operators
should be recursively inferred (obtained distribution from the Table) when they
are created. Now a broadcast-distributed LogicalFilter has no distribution
attribute for its input, which looks too weird.
2.Perhaps we should consider improving processing of RelSubset and HepRelVertex
in RelMdDistribution to prevent the default single distribution when doing
recursive inference. The phenomenon that a broadcast-distributed LogicalFilter
becomes a single-distributed LogicalFilter is also very confusing.
Besides, I think as [~suibianwanwan33] and [~jensen] said (if I understand
correctly), we should not explicitly add the logic about HepRelVex/RelSubset in
the rules, which should be the job of the Hep/VolcanoPlanner.
> 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)
