calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 张静 <jinyuzhangj...@gmail.com>
Subject 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?
Date Thu, 08 Mar 2018 02:42:25 GMT
@chunhui shi, @Julian,
 I got it, thanks a lot.

2018-03-07 16:02 GMT+08:00 Julian Hyde <jhyde@apache.org>:

> 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, 张静 <jinyuzhangjing@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.shi@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, "张静" <jinyuzhangjing@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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message