[
https://issues.apache.org/jira/browse/CALCITE-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822387#comment-16822387
]
Stamatis Zampetakis commented on CALCITE-2973:
----------------------------------------------
bq. Both EnumerableHashJoin and EnumerableMergeJoin should be extended to be
able to deal with non-equijoin, as long as there is a join condition with
equality operator and both sides of the operator uses columns from each single
relation
I think this JIRA/PR are doing the job for EnumerableHashJoin so I guess we
could merge it back quite easily.
[~hhlai1990], as [~hyuan] said probably the only thing that needs to be changed
is instead of creating a new class EnumerableThetaHashJoin you should rather
modify EnumerableJoin.
The various renamings of joins are in progress in CALCITE-2969, so I don't
think we should worry about that here.
> Allow theta joins that have equi conditions to be executed using a hash join
> algorithm
> --------------------------------------------------------------------------------------
>
> Key: CALCITE-2973
> URL: https://issues.apache.org/jira/browse/CALCITE-2973
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.19.0
> Reporter: Lai Zhou
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now the EnumerableMergeJoinRule only supports an inner and equi join.
> If users make a theta-join query for a large dataset (such as 10000*10000),
> the nested-loop join process will take dozens of time than the sort-merge
> join process .
> So if we can apply merge-join or hash-join rule for a theta join, it will
> improve the performance greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
