[ 
https://issues.apache.org/jira/browse/CALCITE-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852674#comment-16852674
 ] 

Lai Zhou commented on CALCITE-2973:
-----------------------------------

[~rubenql],[~michaelmior], now the patch is good enough to be merged.

I adopt my initial solution to support the non inner join with mixed  
conditions(equi conditions and non-equi conditions):

introducing an EnumerablePredicativeHashJoin(before I call it 
EnumerableThetaHashJoin) .

The EnumerablePredicativeHashJoin and EnumerableHashJoin share the same hash 
join algorithm, but EnumerablePredicativeHashJoin extends Join rather than 
EquiJoin.

I believe this solution will do  no harm to current rules, but in the long 
term, we'd better change the EnumerableHashJoin to extend Join.

[~hyuan] created an issue to work on this, see 
https://issues.apache.org/jira/browse/CALCITE-3089.

So, I think we can resolved this issue first.

 

 

> 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
>             Fix For: 1.20.0
>
>          Time Spent: 3h 50m
>  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)

Reply via email to