I agree with the answers already given. I’ll add that “safely” is the key word 
here. Volcano may happen to fire rules in a particular order, but we didn’t 
design in any particular order. If you tweak the “importance” metric you may be 
able to alter the ordering in many cases, but there will still be cases where 
it fires rules in a different order.

HepPlanner, on the other hand, is more rigid (and therefore predictable) in 
which rules it fires, and when. Consider adding a mode to HepPlanner that fires 
rules in the order you want.

> On Mar 5, 2018, at 9:18 PM, 张静 <jinyuzhangj...@gmail.com> wrote:
> Hi, chunhui shi
> Thanks a lot. I find that at the beginning of the optimize process, initial
> importances of each volcanoRuleMatch in RuleQueue are computed by depth, So
> the rule matched the nodes which are colser to root has bigger importance,
> but I'm not sure whether  after importance updated or boosted during
> optimize process.
> 2018-03-06 11:37 GMT+08:00 Chunhui Shi <chunhui....@gmail.com>:
>> I think the answer is no.
>> At least that is my impression with volcano planner in latest Calcite.
>> Matched rules will be categorized by matching root nodes' classes. And the
>> execution, which is, the onMatch() function, will be executed in the order
>> of iterating through the categories. So the order is not related to the
>> relnode level or the order of rules in the rule list.
>> On Mar 5, 2018 7:02 PM, "张静" <jinyuzhangj...@gmail.com> wrote:
>> Hi, guys.
>> Can we safely assuming that the rules match nodes which are closer to root
>> would execute earlier than those rules  matches nodes which are closer to
>> tableScan?
>> For the following nodes tree, can we assume the rules matches aggregate are
>> always execute earlier than the rules matches filter?
>> Aggregate
>> |_Project
>>             |_Filter
>>                       |_TableScan

Reply via email to