implementation rules, or
>>> even logical exploration rules, But each rule is independent, the
>>> pattern-matched expression is not aware of what does the parent operator
>>> want. Using AbstractConverter doesn't help, and is not promising.
>>>
>>> &g
e-66ab426494c1.h.y...@alibaba-inc.com%3e
- Haisheng
--
发件人：Vladimir Ozerov
日 期：2019年12月06日 18:00:01
收件人：Haisheng Yuan
抄 送：dev@calcite.apache.org (dev@calcite.apache.org)
主 题：Re: Re: Re: Volcano's problem with trait propagation: current state and
future
"all we know is their collations"
gt; > }
> >> > >
> >> > > // This is a good implementation. Register it in the
> >> set,
> >> > > updating per-traitset best costs.
> >> > > equivalenceSet.register(physicalJoin);
> >&g
gt;
>> > > This is a very rough pseudo-code, only to demonstrate the basic idea
>> on
>> > > how proper bottom-up propagation not only helps us set proper traits
>> for
>> > > the new physical node but also ensures that not optimal plans are
>>
way
> > is
> > > to add the aforementioned physical routine to normal Volcano flow:
> > > 1) Fire logical rule on a node and register new nodes
> > > 2) Fire physical optimization as shown above, then invoke
> > > "call.transformTo()" for every ret
> they trigger each other recursively. But this would require a serious
> > redesign of a "rule queue" concept.
> >
> > Does it have any common points with your proposal?
> >
> > Regards,
> > Vladimir.
> >
> > [1]
> >
> https://ponymail-vm.apache.org/_GUI_/thread.
which is not ideal. But we can't say Calcite is doing wrong.
>>
>> Ideally, we expect it generates multiple (neither all, nor single)
>> bipartie graphs. The join reordering rule will cut each part into bipartie
>> recursively and apply JoinCommutativity rule to generate more
gy. We can modify the rule,
> or create new join reordering rule to generate multiple plan alternatives.
>
> - Haisheng
>
> --
> 发件人：Haisheng Yuan
> 日 期：2019年12月06日 09:07:43
> 收件人：Vladimir Ozerov; dev@calcite.apache.o
--
发件人：Haisheng Yuan
日 期：2019年12月06日 09:07:43
收件人：Vladimir Ozerov; dev@calcite.apache.org
(dev@calcite.apache.org)
主 题：Re: Re: Volcano's problem with trait propagation: current state and future
Generally agree with what Vladimir said. I
seems like the proposal of API change gets no
love.
- Haisheng
--
发件人：Vladimir Ozerov
日 期：2019年12月05日 22:22:43
收件人：dev@calcite.apache.org (dev@calcite.apache.org)
主 题：Re: Volcano's problem with trait propagation: current state and f
10 matches
Mail list logo
