You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Q L (Jira)" <ji...@apache.org> on 2020/02/06 14:46:00 UTC

[jira] [Comment Edited] (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&focusedCommentId=17031633#comment-17031633 ] 

Ruben Q L edited comment on CALCITE-3285 at 2/6/20 2:45 PM:
------------------------------------------------------------

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.


was (Author: rubenql):
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)