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