Haisheng Yuan created CALCITE-3896:
--------------------------------------
Summary: Pass through parent trait requests to child operators
Key: CALCITE-3896
URL: https://issues.apache.org/jira/browse/CALCITE-3896
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Haisheng Yuan
This is not on-demand trait requests as described in [mailing
list|http://mail-archives.apache.org/mod_mbox/calcite-dev/201910.mbox/%3cd75b20f4-542a-4a73-897e-66ab426494c1.h.y...@alibaba-inc.com%3e],
which requires the overhaul of the core planner. This ticket tries to enable
VolcanoPlanner with basic and minimal ability to pass through parent trait
request to child operators without rules, though may not be flexible or
powerful, but should be able to work with current Calcite application with
minimal changes.
The method for physical operators to implement would be:
{code:java}
interface PhysicalNode {
RelNode passThrough(RelTraitSet required);
}
{code}
Given that Calcite's physical operators decides its child operators' traits
when the physical operator is created in physical implementation rule, there
are some drawback that can't be avoided. e.g., given the following plan:
{code:java}
StreamAgg on [a]
+-- MergeJoin on [a, b, c]
|--- TableScan foo
+--- TableScan bar
{code}
Suppose the MergeJoin implementation rule generates several mergejoins that
distributes by [a], [a,b], [a,b,c]. Then we pass parent operator StreamAgg's
trait request to MergeJoin. Since MergeJoin[a] satisfies parent's request,
nothing to do. Next pass request to MergeJoin[a,b], we get MergeJoin[a], then
pass request to MergeJoin[a,b,c], we get MergeJoin[a] again. We know they are
redundant and there is no need to pass through parent operator's trait request,
but these MergeJoin operators are independent and agnostic of each other's
existence.
The ideal way is that in physical implementation rule, during the creation of
physical operator, it should not care about itself and its child operators'
physical traits. But this is another different topic.
Anyway, better than nothing, once it is done, we can provide the option to
obsolete or disable {{AbstractConverter}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
