hsyuan 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_r279996918
##########
File path: core/src/main/java/org/apache/calcite/plan/RelOptUtil.java
##########
@@ -3734,6 +3740,13 @@ private Exists(RelNode r, boolean indicator, boolean
outerJoin) {
this.outerJoin = outerJoin;
}
}
+
+ /** Check if it is the join whose condition is based on column equality. */
+ public static boolean isEquiJoin(Join join) {
+ return join.isNonCorrelateSemiJoin()
+ || join instanceof EnumerableHashJoin
+ || join instanceof EnumerableMergeJoin;
+ }
Review comment:
I would rather trust Oracle's documentation about `EquiJoin`:
https://docs.oracle.com/cd/E11882_01/server.112/e41084/queries006.htm#SQLRF52350
However, it is meaningless and pedantic to argue what is an EquiJoin. Think
about this question. What makes the so-called `EquiJoin` special? Is it because
we can create hash join or merge join for it? If yes, the `EquiJoin` should be
removed. As long as there is an equality join condition, both sides of the
equality operator contain columns from single table, and there is no subquery
in the condition, and both sides are hashable or sortable, even it is not a
so-called `EquiJoin`, we can still create hash join or merge join for it. The
current `EquiJoin` in Calcite has so many limitations. Even though we can make
additional project to make each side become a single column to satisfy
`EquiJoin`, it will add another operator, adding additional execution cost.
----------------------------------------------------------------
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:
us...@infra.apache.org
With regards,
Apache Git Services
