[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062769#comment-17062769 ] Ruben Q L commented on CALCITE-3285: Fixed via [https://github.com/apache/calcite/commit/f76ddd1f02af2d6d335a82acc92a30ccf6d7379d] Many thanks to [~vladimirsitnikov] for his suggestions which helped to improve the patch! > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Time Spent: 9h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060036#comment-17060036 ] Ruben Q L commented on CALCITE-3285: Recap: [PR#1788|https://github.com/apache/calcite/pull/1788] proposes a solution for the current ticket which: - a) does not break backwards compatibility - b) it is in any case flagged as "Experimental" At this stage, if no-one objects within three days, I'll assume lazy consensus, commit it and move this ticket as "Resolved". > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056997#comment-17056997 ] Ruben Q L commented on CALCITE-3285: [~zabetak], thanks for your comment. I have no problem in flagging the new API as experimental. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056845#comment-17056845 ] Stamatis Zampetakis commented on CALCITE-3285: -- Everybody in this discussion seem to agree that the merge join should support non-equi join conditions, if the condition contains at least one equality conjunction. I had a quick look in [PR#1788|https://github.com/apache/calcite/pull/1788] and it seems that it can achieve this purpose without any significant overhead for the case of equi-joins thus I think it is a good step forwards. [~vladimirsitnikov] raised some concerns regarding the usefulness of the new API in EnumerableDefaults. In order to move forward, I would suggest to mark this API as experimental and if in the near future somebody has a better idea of how to tackle this problem we can easily remove it. How do people feel about this? > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055777#comment-17055777 ] Ruben Q L commented on CALCITE-3285: Could we please re-consider merging [PR#1788|https://github.com/apache/calcite/pull/1788] in order to have a pragmatic solution for this issue in the short term? To sum up, this fix proposes having a predicate with the non-equi clauses of the join condition (which will be null in case of equi joins). Pros: - Full support of all types of conditions in MergeJoin (equi and non-equi), which is the goal of the current ticket. - No regression for equi-joins (they will behave as before, so we should see no performance regression in there). - It allows future work on the MergeJoin in order to support other join types (right now only INNER join is supported). In this regard, right now this ticket is blocking some other improvements in the MergeJoin that I would like to include in the short term (CALCITE-3833 _Support SemiJoin_ and CALCITE-3834 _Support AntiJoin_). The other discussed approach to solve the current ticket, based on splitting the join into "mergeJoin(equiCondition) + where(nonEquiCondition)", only works for INNER joins, so it would be able to support CALCITE-3833 and CALCITE-3834. I understand [~vladimirsitnikov] concerns regarding future work on optimizing MergeJoin algorithm, but as I see it, introducing a Predicate with the non-optimizable clause(s) from the MergeJoin condition (as [PR#1788|https://github.com/apache/calcite/pull/1788] proposes) is something IMHO unavoidable in order to handle all type of (non-equi) conditions, as I described on my previous comment. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031700#comment-17031700
]
Ruben Q L commented on CALCITE-3285:
[~vladimirsitnikov], I understand your point.
But even when / if MergeJoin provides an efficient implementation of conditions
like {{a.id > b.id-10 and a.id b.id-10 and a.id
MY_FUNCTION(b.name)}}
> EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031687#comment-17031687
]
Vladimir Sitnikov commented on CALCITE-3285:
The API you add does not leave room for efficient implementation of \{{a.id >
b.id-10 and a.id EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031633#comment-17031633 ] Ruben Q L commented on CALCITE-3285: Thanks for your reply [~vladimirsitnikov]. The solution that you propose in https://github.com/apache/calcite/pull/1702/commits/267e64c51e766d4d2ee05cec433b2759c87284a0 should also solve the issue. However, it is based on the approach of "mergeJoin + where(nonEquiCondition)", which only works for INNER joins. Right now this is no problem, because EnumerableMergeJoin supports only INNER joins; but I'd like to work on this in a short-term, in order to provide EnumerableMergeJoin support for at least LEFT, SEMI and ANTI join (for equi and non-equi conditions), which should not be very costly. If we implement this, the "mergeJoin + where(nonEquiCondition)" approach could not be applied on these join types. The simplest solution would be passing the Predicate parameter an keep the (non-equi) join logic within EnumerableDefaults#mergeJoin, as I propose in my PR. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031626#comment-17031626 ] Vladimir Sitnikov commented on CALCITE-3285: [~rubenql], does [https://github.com/apache/calcite/pull/1702/commits/267e64c51e766d4d2ee05cec433b2759c87284a0] (it is a part of PR1788) solve the issue? I think so. I'm -1 adding various `non-equi join` to linq4j API provided they add no value. I think the proper implementation should support "less than" kind of joins. However, I doubt that implementation is possible with `Predicate` style condition. So adding Predicate argument does not leave room for future improvements. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031602#comment-17031602 ] Ruben Q L commented on CALCITE-3285: Hello guys, I have given this another try, with a simple (naive) solution, but which should give the correct result. Could you please take a look at [PR#1788|https://github.com/apache/calcite/pull/1788]? > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012721#comment-17012721 ] Vladimir Sitnikov commented on CALCITE-3285: Reverted in https://github.com/apache/calcite/commit/820f6ab4965d79946e4144db8e33aeef98c3d2ff > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010004#comment-17010004
]
Julian Hyde commented on CALCITE-3285:
--
{quote}The sad thing is there's no clear way to prevent creating
EnumerableMergeJoin without non-equi join conditions.
{quote}
There is a mechanism. The constructor of the RelNode can throw
InvalidRelException. EnumerableAggregate does this, for instance, when given a
distinct aggregate function.
Let's not over-use this mechanism, but it is a way for particular RelNode
sub-classes to say 'I can't handle this'.
> EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009530#comment-17009530
]
Vladimir Sitnikov commented on CALCITE-3285:
{quote} What if we return infinite cost in EnumerableMergeJoin#computeSelfCost
if the join is not "implementable" with the current merge algorithm (non-equi
join / outer join)?{quote}
That might prevent selecting that as the final plan, however, it would not
prevent the optimizer from trying apply all those rules.
The cost might be infinite for multiple reasons:
1) An appropriate input is missing. For instance, one of the inputs is not yet
converted to enumerable.
2) A wrong join type is used. For instance, non-equi merge join. It would be
better to avoid creating those relations rather than create them and then try
to return infinite cost for them.
> EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009487#comment-17009487
]
Ruben Q L commented on CALCITE-3285:
What if we return infinite cost in {{EnumerableMergeJoin#computeSelfCost}} if
the join is not "implementable" with the current merge algorithm (non-equi join
/ outer join)?
> EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009405#comment-17009405 ] Vladimir Sitnikov commented on CALCITE-3285: The sad thing is there's no clear way to prevent creating EnumerableMergeJoin without non-equi join conditions. In other words, even if EnumerableMergeJoinRule would create just trivial joins that has only equi conditions, other rules (FilterJoinRule) might push filters into the join converting it into non-equi join. So either we need a way to tell if a join instance supports non-equi conditions (or if it supports outer joins), or we need to implement that through extra filter at the Enumerablerel#implement phase. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009375#comment-17009375 ] Haisheng Yuan commented on CALCITE-3285: If we change to mergeJoin(...).where(...), why don't we just revert the code? > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007899#comment-17007899
]
Jin Xing commented on CALCITE-3285:
---
Hi, [~vladimirsitnikov] ~
Thanks a lot for the fix PR-1702 ~
Now I understand that the result type of *mergeJoin* is as below
{code:java}
ImmutableList.of(leftResult.physType, rightResult.physType)
{code}
And we can filter the values using predicate.
Fixing by *mergeJoin(...).where(...)* can keep the code backward compatibility
and make the code clean.
> EnumerableMergeJoin should support non-equi join conditions
> ---
>
> Key: CALCITE-3285
> URL: https://issues.apache.org/jira/browse/CALCITE-3285
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Calcite should be able to generate EnumerableMergeJoin with non-equi join
> conditions, as long as there are equi-join conditions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007796#comment-17007796 ] Haisheng Yuan commented on CALCITE-3285: [~vladimirsitnikov] I checked your fix at https://github.com/apache/calcite/pull/1702/commits/686d985d4a45b1306d4d397ad51e6cc03fe3ba4d, in which you extract non-equi condition on top of MergeJoin, that may still generate wrong result for outer joins: select * from foo left join bar on foo.a=bar.a and foo.b > bar.c; > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007788#comment-17007788 ] Julian Hyde commented on CALCITE-3285: -- In order to increase the capabilities of EnumerableMergeJoin you have to make it much slower. It has to scan all remaining rows on the right-hand side, rather than just scan a few rows until the key changes. Rather than fixing CALCITE-3667 I think you need to revert CALCITE-3285. > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006842#comment-17006842 ] Jin Xing commented on CALCITE-3285: --- Hi [~vladimirsitnikov] Yes, you are right, it's a bug. I filed a JIRA -- CALCITE-3667 and proposed a fix [1]. It'd be great if you can take a look when you have time ~ Best, Jin https://github.com/apache/calcite/pull/1717 > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006820#comment-17006820 ] Jin Xing commented on CALCITE-3285: --- Thanks for ping me [~vladimirsitnikov] I will verify soon ~ > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006383#comment-17006383 ] Vladimir Sitnikov commented on CALCITE-3285: [~jinxing6...@126.com], [~hyuan] it looks like MergeJoin implementation is not symmetrical. In other words, the resultset depends on the order of the inputs. For instance, org.apache.calcite.runtime.EnumerablesTest#testMergeJoin4. If I swap join inputs, then the join suddenly produces 2 rows instead of 4. I have not verified which one is better, but merge join should be symmetrical. Can you please check that? > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
