hub.com
> > > > [3]
> > https://community.apache.org/apache-way/apache-project-maturity-model.html#quality
> > > >
> > > > > On Apr 14, 2019, at 14:53, Walaa Eldin Moustafa
> > > > >
> > wrote:
> > > > >
> > > >
ty-model.html#quality
> >>
> >>> On Apr 14, 2019, at 14:53, Walaa Eldin Moustafa
> wrote:
> >>>
> >>> Agreed, but not sure what would the best way to do it be without
> >>> making the code very confusing.
> >>>
> >>
ove SEMI instance and change the matchs condition
>>>>> to !join.getJoinType().generatesNullsOnLeft() which also allowed ANTI
>>>>> compared before this patch.
>>>>> - SemiJoinRule match SEMI join specificlly
>>>>>
>>>>> ### Metadata tweak
>>>>> - RelMdAllPredicates, RelMdExpressionLineage: Add full rowType to
>>>>> getAllPredicates(Join) cause semi-join only outputs one side
>>>>> - RelMdColumnUniqueness, RelMdSelectivity, RelMdDistinctRowCount,
>>>>> RelMdSize, RelMdUniqueKeys: merge semi-join logic to join
>>>>>
>>>>>
>>>>> ### Test cases change
>>>>> - MaterializationTest#testJoinMaterialization11 now can materialize
>>>>> successfully, cause i allow logical SemiJoin node to match, the original
>>>>> matchs SemiJoin as SemiJoin.class.isAssignableFrom(), which i think is
>>>>> wrong cause this will only matches subClasses of SemiJoin which is only
>>>>> EnumerableSemiJoin before this patch.
>>>>> - SortRemoveRuleTest#removeSortOverEnumerableCorrelate, because
>>>>> CALCITE-2018, the final EnumerableSort's cost was cache by the previous
>>>>> EnumerableSort with logical childs, so i remove the EnumerableSortRule and
>>>>> the best plan is correct
>>>>> - sub-query.iq has better plan for null correlate
>>>>>
>>>>>
>>>>>
>>>>> Best,
>>>>> Danny Chan
>>>>> 在 2019年3月21日 +0800 AM3:07,Julian Hyde ,写道:
>>>>>> I just discovered that Correlate, which is neither a Join nor a
>>>>> SemiJoin, uses SemiJoinType, but SemiJoin does not use SemiJoinType.
>>>>>>
>>>>>> Yuck. The Join/SemiJoin/Correlate type hierarchy needs some thought.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>>
>>>>>
>>>>
>>
ot sure what would the best way to do it be without
> > making the code very confusing.
> >
> > On Sat, Apr 13, 2019 at 2:46 PM Haisheng Yuan
> > wrote:
> > >
> > > I share the same concern with you.
> > >
> > >
> > >
> > >
>
e the same concern with you.
>>
>>
>>
>>
>>
>> Thanks~
>> Haisheng
>> Yuan------
>> 发件人:Stamatis Zampetakis
>> 日 期:2019年04月14日 05:37:29
>> 收件人:
>> 主 题:Re: Join, SemiJoin, Correlate
>&g
anks~
> Haisheng
> Yuan--
> 发件人:Stamatis Zampetakis
> 日 期:2019年04月14日 05:37:29
> 收件人:
> 主 题:Re: Join, SemiJoin, Correlate
>
> Hi Danny,
>
> Thanks a lot for taking this on, it is a great start!
>
> I didn't look thoroughly through the PR but I noticed that there a
Thx, Stamatis and Haisheng Yuan
I did rename EnumerableCorrelate and EnumerableJoin, your suggestions
are reasonable, I
would add them back and mark as deprecated.
For Correlate and LogicalCorrelate i already keep the old constructor and
method #create().
I will recheck if there are some APIs
Stamatis and Haisheng Yuan
I did rename EnumerableCorrelate and EnumerableJoin, your suggestions
are reasonable, I would add them back and mark as deprecated.
For Correlate and LogicalCorrelate i already kept the old constructor and
method #create().
I will recheck if there are some APIs
I share the same concern with you.
Thanks~
Haisheng Yuan--
发件人:Stamatis Zampetakis
日 期:2019年04月14日 05:37:29
收件人:
主 题:Re: Join, SemiJoin, Correlate
Hi Danny,
Thanks a lot for taking this on, it is a great start!
I didn't look
the best plan is correct
> - sub-query.iq has better plan for null correlate
>
>
>
> Best,
> Danny Chan
> 在 2019年3月21日 +0800 AM3:07,Julian Hyde ,写道:
> > I just discovered that Correlate, which is neither a Join nor a
> SemiJoin, uses SemiJoinType, but SemiJoin does not use SemiJoinType.
> >
> > Yuck. The Join/SemiJoin/Correlate type hierarchy needs some thought.
> >
> > Julian
> >
> >
>
oin,
> uses SemiJoinType, but SemiJoin does not use SemiJoinType.
>
> Yuck. The Join/SemiJoin/Correlate type hierarchy needs some thought.
>
> Julian
>
>
Correlate (or Apply) can be
> > > transformed into a Join, or a Join
> > > > is transfomed into a Correlate (Or Apply), in case there is an index
> can
> > > be used in inner relation.
> > > >
> > > > What I am not comfortable with is:
> > > > In SQL Server and GPDB Orca optimzier, Sql
nslated into logical
> > relation as it should be (
> > > keep subquery as it is), then use all kinds of apply rules to unnest
> > subqueries based on cost model,
> > > which seems reasonable to me.
> > > But in Calcite, we can not only decorrelate in S
me.
> > But in Calcite, we can not only decorrelate in SqlToRel stage, but also
> can do it in SubqueryRemoveRule.
> > Should we unify them all in the rules and keep SqlToRelConverter simple?
> >
> > Thanks ~
> > Haisheng Yuan
> > --
t; Haisheng Yuan
> ------
> 发件人:Stamatis Zampetakis
> 日 期:2019年03月23日 07:31:35
> 收件人:
> 主 题:Re: Join, SemiJoin, Correlate
>
> Since we are discussing this topic I thought it would be could to bring
> back
> to the
ubPlan (in Postgres’ term) is a Postgres physical relational node to
>>> evaluate correlated subquery. What I mean is correlated subquery that can’t
>>> be decorrelated can’t be implemented by hashjoin or mergejoin. But it is
>>> off topic.
>>>
>>> Tha
, but also can do
it in SubqueryRemoveRule.
Should we unify them all in the rules and keep SqlToRelConverter simple?
Thanks ~
Haisheng Yuan
--
发件人:Stamatis Zampetakis
日 期:2019年03月23日 07:31:35
收件人:
主 题:Re: Join, SemiJoin, Correlate
Since we
>
> > Thanks ~
> > Haisheng Yuan
> > ------
> > 发件人:Walaa Eldin Moustafa
> > 日 期:2019年03月21日 09:31:41
> > 收件人:
> > 抄 送:Stamatis Zampetakis
> > 主 题:Re: Re: Join, SemiJoin, Correlate
> >
>
y. What I mean is correlated subquery that can’t
> be decorrelated can’t be implemented by hashjoin or mergejoin. But it is
> off topic.
> >
> > Thanks ~
> > Haisheng Yuan
> > ------
> > 发件人:Walaa El
ive because it lets Join, SemiJoin
> and Correlate continue to be structurally different.
> > >>
> > >> Julian
> > >>
> > >>
> > >>
> > >>
> > >>> On Mar 20, 2019, at 6:55 PM, Haisheng Yuan
> wrote:
> > >>>
t;>>
> >>> SubPlan (in Postgres’ term) is a Postgres physical relational node to
> >>> evaluate correlated subquery. What I mean is correlated subquery that
> >>> can’t be decorrelated can’t be implemented by hashjoin or mergejoin. But
> >>>
subquery that can’t
>>> be decorrelated can’t be implemented by hashjoin or mergejoin. But it is
>>> off topic.
>>>
>>> Thanks ~
>>> Haisheng Yuan
>>> --
>>>
can’t be implemented by hashjoin or mergejoin. But it is
> > off topic.
> >
> > Thanks ~
> > Haisheng Yuan
> > ------
> > 发件人:Walaa Eldin Moustafa
> > 日 期:2019年03月21日 09:31:41
> > 收件人:
> > 抄 送:Stamatis Zampetakis
> > 主 题:Re: Re: Join,
> 收件人:
> 抄 送:Stamatis Zampetakis
> 主 题:Re: Re: Join, SemiJoin, Correlate
>
> Agreed with Stamatis. Currently: 1) Correlate is tied to IN, EXISTS,
> NOT IN, NOT EXISTS, and 2) is used as an equivalent to nested loops
> join. The issues here are: 1) IN, EXISTS, NOT IN, NOT EX
--
发件人:Walaa Eldin Moustafa
日 期:2019年03月21日 09:31:41
收件人:
抄 送:Stamatis Zampetakis
主 题:Re: Re: Join, SemiJoin, Correlate
Agreed with Stamatis. Currently: 1) Correlate is tied to IN, EXISTS,
NOT IN, NOT EXISTS, and 2) is used as an equivalent to nested loops
join. The issues
> Thanks ~
> Haisheng Yuan
> --
> 发件人:Stamatis Zampetakis
> 日 期:2019年03月21日 07:13:15
> 收件人:
> 主 题:Re: Join, SemiJoin, Correlate
>
> I have bumped into this quite a few times and I think we should really try
&
in Calcite, or SubPlan
in Postgres’s terminology, but it can’t be implemented as HashJoin or MergeJoin.
Thanks ~
Haisheng Yuan
--
发件人:Stamatis Zampetakis
日 期:2019年03月21日 07:13:15
收件人:
主 题:Re: Join, SemiJoin, Correlate
I have bumped
I just discovered that Correlate, which is neither a Join nor a SemiJoin,
> uses SemiJoinType, but SemiJoin does not use SemiJoinType.
>
> Yuck. The Join/SemiJoin/Correlate type hierarchy needs some thought.
>
> Julian
>
>
>
I just discovered that Correlate, which is neither a Join nor a SemiJoin, uses
SemiJoinType, but SemiJoin does not use SemiJoinType.
Yuck. The Join/SemiJoin/Correlate type hierarchy needs some thought.
Julian
29 matches
Mail list logo