You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Haisheng Yuan (Jira)" <ji...@apache.org> on 2020/04/04 20:47:00 UTC
[jira] [Updated] (CALCITE-3896) Pass through parent trait requests
to child operators
[ 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/%3cd75b20f4-542a-4a73-897e-66ab426494c1.h.yuan@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] 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/%3cd75b20f4-542a-4a73-897e-66ab426494c1.h.yuan@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}}.
> 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/%3cd75b20f4-542a-4a73-897e-66ab426494c1.h.yuan@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] 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)