rubenada commented on a change in pull request #1157: [CALCITE-2969] Improve
design of join-like relational expressions
URL: https://github.com/apache/calcite/pull/1157#discussion_r276557077
##########
File path:
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableThetaJoin.java
##########
@@ -45,6 +46,7 @@
/** Implementation of {@link org.apache.calcite.rel.core.Join} in
* {@link org.apache.calcite.adapter.enumerable.EnumerableConvention
enumerable calling convention}
* that allows conditions that are not just {@code =} (equals). */
+@Deprecated // to be removed before 2.0
Review comment:
Actually, looking at BuiltInMethod.THETA_JOIN, I agree it is the pure
definition of a NestedLoopJoin (without the correlating variable mechanism).
So, it would seem that we two implementations of nested loop join
(EnumerableCorrelate and EnumerableThetaJoin). What if we did the following:
- Rename EnumerableThetaJoin as EnumerableNestedLoopJoin: right now this is
most powerful (albeit most likely inefficient) way to implement any type of
join: inner, left, right, outer; with equi or non-equi condition (although the
inner and equi ones actually go through EnumerableJoin for efficiency). And I
think EnumerableThetaJoin will allow us to implement non-equi semijoins too.
- Keep EnumerableCorrelate as it is, do not rename it. I agree that it is
also a nested loop implementation, but it uses the correlating variable
approach, so I think keeping its current name will keep things clearer.
This is an alternative approach that differs from the original idea, I'm not
sure if it's the right one, but me be worth to discuss it,
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
