[
https://issues.apache.org/jira/browse/CALCITE-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-3896:
-----------------------------------
Description:
This is not on-demand trait requests as described in [mailing
list|http://mail-archives.apache.org/mod_mbox/calcite-dev/201910.mbox/%[email protected]%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] separately. 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}}.
was:
This is not on-demand trait requests as described in [mailing
list|http://mail-archives.apache.org/mod_mbox/calcite-dev/201910.mbox/%[email protected]%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}}.
> 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
> Priority: Major
>
> This is not on-demand trait requests as described in [mailing
> list|http://mail-archives.apache.org/mod_mbox/calcite-dev/201910.mbox/%[email protected]%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] separately. 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)
