Re: 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?

@chunhui shi, @Julian, I got it, thanks a lot. 2018-03-07 16:02 GMT+08:00 Julian Hyde : > 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

Re: 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?

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

Re: 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?

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

Re: 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?

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