[
https://issues.apache.org/jira/browse/CALCITE-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985100#comment-16985100
]
Ruben Q L commented on CALCITE-3535:
------------------------------------
Thanks for your comments, [~jinxing6...@126.com].
I think that, even with the improvements in EnumerableNestedLoopJoin done via
CALCITE-3546, we should keep EnumerableJoinRule's behavior as it is right now:
- If there's at least one "equi condition" in the join: go for a HashJoin
- Otherwise (the join condition is completely non-equi-join): go for a
NestedLoopJoin
I think that with at least one "equi condition", the HashJoin strategy should
be more time-efficient than a NestedLoopJoin (CALCITE-3546 will help us save
some memory in the NestedLoopJoin , but time-wise the performance will still be
the same: two nested loops to perform the join) . In any case, I prefer to keep
EnumerableJoinRule's behavior in this patch, which is merely a "refactoring to
avoid an extra filter".
And yes, maybe EnumerableJoinRule's name could be reviewed. Now that hash joins
can accept any type of condition, we could even have two different rules:
EnumerableHashJoinRule (which would always create a HashJoin), and
EnumerableNestedLoopJoinRule (which would always create a NestedLoopJoin); and
we could deprecate the current EnumerableJoinRule with that change. But IMO
this should be addressed in a separate ticket.
> EnumerableJoinRule: remove unnecessary Filter on top of INNER Join
> ------------------------------------------------------------------
>
> Key: CALCITE-3535
> URL: https://issues.apache.org/jira/browse/CALCITE-3535
> Project: Calcite
> Issue Type: Task
> Components: core
> Affects Versions: 1.21.0
> Reporter: Ruben Q L
> Assignee: Ruben Q L
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the implementation of CALCITE-2973, now EnumerableHashJoin supports all
> type of conditions (not just equi joins). However, there is still one
> [TODO|https://github.com/apache/calcite/blob/07c1efbb2b42a0e27f9d01968d357d9c1e17cd51/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableJoinRule.java#L89]
> in EnumerableHashJoinRule that, in case of an INNER Join, creates a Filter
> with the non-equi conditions on top of the EnumerableHashJoin (created only
> with the equi-conditions), this filter is not really needed, since now
> EnumerableHashJoinRule can support the full condition: equi and non-equi
> items.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
