Description
This is not on-demand trait requests as described in mailing list, 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:
interface RelNode {
RelNode passThrough(RelTraitSet required);
}
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:
StreamAgg on [a]
+-- MergeJoin on [a, b, c]
|--- TableScan foo
+--- TableScan bar
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, but still be able to do property enforcement.
Attachments
Issue Links
- relates to
-
CALCITE-4008 Implement Code generation for EnumerableSortedAggregate
-
- Closed
-
-
CALCITE-4052 Enable Top-down Optimization
-
- Open
-
