[
https://issues.apache.org/jira/browse/CALCITE-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100596#comment-17100596
]
Jinpeng Wu commented on CALCITE-3916:
-------------------------------------
PR: https://github.com/apache/calcite/pull/1950
There might be two ways to accomplish this. The first one is designing another
Planner while the second is modifying the VolcanoPlanner directly and make sure
it won't break the current logic. The pros and cons are discussed:
https://lists.apache.org/thread.html/r38ea71968c069f465921e7197488329c15413b46831c90ad4d48f87e%40%3Cdev.calcite.apache.org%3E
My code is now generally on the first track. Currently it should not be
difficult to switch to the second one. However, I am still trying some
aggressive optimizations. So I am not going to take the second way until many
people insist. Thanks
> Support cascades style top-down driven rule apply
> -------------------------------------------------
>
> Key: CALCITE-3916
> URL: https://issues.apache.org/jira/browse/CALCITE-3916
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Assignee: Jinpeng Wu
> Priority: Major
>
> Apply rules by leaf RelSet -> root RelSet order. For every RelNode in a
> RelSet, rule is matched and applied sequentially. No RuleQueue and
> DeferringRuleCall is needed anymore. This will make space pruning and rule
> mutual exclusivity check possible.
> Rule that use AbstractConverter as operand is an exception, to keep backward
> compatibility, this kind of rule still needs top-down apply.
> This should be done after CALCITE-3896.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
