Jinfeng Ni's proposal +1, enhance method satisfies maybe more reasonable.
Danny Chan's thoughts +1
Regards!
Aron Tao
XING JIN 于2019年11月8日周五 下午8:09写道：
> Hi Haisheng,
>
> Thanks a lot for sharing this great proposal ~
> For short I understand your idea as below:
> 1. Derive the distribution
Hi Haisheng,
Thanks a lot for sharing this great proposal ~
For short I understand your idea as below:
1. Derive the distributions/collations that children COULD/MIGHT offer
2. Decide the best distributions/collations by first point and computing
logic of operator, say gropuings in Aggregate;
It
@Haisheng, @Xiening,
Thanks for pointing that previous email out. Overall, I agree that
the physical trait enforcement should be done in the engine, not in
the rule. For the rule, it should only specify the request, and the
corresponding transformation, and let the engine to explore the search
sp
Hi Jinfeng,
I think you might have missed the email about proposed API for physical
operators I sent out previously in [1].
We don't need request all the permutation, which is also impossible in
practice, the search space is going to explode.
In the example in email [1], I already talked about
te/rel/metadata/RelMdCollation.java
--Original Mail --
Sender:Haisheng Yuan
Send Date:Fri Oct 25 12:01:40 2019
Recipients:dev@calcite.apache.org (dev@calcite.apache.org)
Subject:Re: Re: Re: [DISCUSS] On-demand traitset request
I didn't say adding to RelNode, but a n
：
主 题：Re: Re: [DISCUSS] On-demand traitset request
I have the same feeling, it seems to much interfaces for the physical node(we
do not really have physical class for physical nodes yet), so these interfaces
may just be put into the RelNode, that was too complex and to much for me, can
we have
I would like a further clarification regarding the methods:
derivedDistribution()
derivedCollation()
What would be the difference with the existing derivation mechanism in
RelMdDistribution [1], and RelMdCollation [2].
They are not sufficient to provide the necessary information?
[1]
https://gith
I have the same feeling, it seems to much interfaces for the physical node(we
do not really have physical class for physical nodes yet), so these interfaces
may just be put into the RelNode, that was too complex and to much for me, can
we have a way that do not modify the nodes itself ?
Best,
D
)
public T derivedTrait(RelTraitDef traitDef)
- Haisheng
--
发件人：Stamatis Zampetakis
日 期：2019年10月23日 14:53:38
收件人：
主 题：Re: Re: [DISCUSS] On-demand traitset request
Overall, I agree that better encapsulation of propagation and derivation of
Overall, I agree that better encapsulation of propagation and derivation of
traits would be beneficial for our system.
Regarding the API proposed by Haisheng, I have to think a bit more on it.
At first glance, adding such methods directly in the RelNode API does not
appear an ideal solution since
To Stamatis,
Not exactly. My initial thought was giving the physical operator the abiity to
customize and fully control physical property derivation strategy, thus can
further help the purpose driven trait request. But since we agree to think more
high-level API to support on-demand traitset req
A little bit of history. In Drill, when we first implemented
Distribution trait's definition, we allows both exact match and
partial match in satisfy() method. This works fine for single-input
operator such aggregation, however it leads to incorrect plan for join
query, i.e LHS shuffle with (a,
This is an interesting topic. Thanks for bringing up this issue.
My understanding of Volcano planner is it works in a top-down search
mode (the parent asks for certain trait of its child), while the trait
propagates in a bottom-up way, as Stamatis explained.
IMHO, the issue comes down to the defi
Hi Stamatis,
Thanks for your comment. I think my example didn't make it clear.
When a logical operator is created, it doesn't have any physical,
propertyand it shouldn't have. When a physical operator is created,
e.g. in Enumerable convention, it only creates an intuitive traitset
with it, and re
14 matches
Mail list logo
