libenchao commented on code in PR #3311:
URL: https://github.com/apache/calcite/pull/3311#discussion_r1314806469
##########
linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java:
##########
@@ -4495,6 +4492,27 @@ private boolean advanceRight(TInner right, TKey
rightKey) {
}
}
+ public static int compareNullsLastForMergeJoin(@Nullable Comparable v0,
@Nullable Comparable v1) {
+ return compareNullsLastForMergeJoin(v0, v1, null);
+ }
+
+ public static int compareNullsLastForMergeJoin(@Nullable Comparable v0,
@Nullable Comparable v1,
+ @Nullable Comparator comparator) {
+ // Special code for mergeJoin algorithm: in case of two null values, they
must not be
+ // considered as equal (otherwise the join would return incorrect
results); instead, consider
+ // the first (left) value as "bigger", to advance on the right value and
continue with the
+ // algorithm
+ if (v0 == null && v1 == null) {
+ return 1;
Review Comment:
IIUC, sort merge join has two stages, firstly, it sorts the inputs from both
side, then do the merge. For the current implementation, the `Comparator` is
used in both stages, and we only test the case for second stage. What I'm
concerned about is it may affect the first stage, so we'd better to have a test
case about it to ensure it works expectedly and will not be broken in the
future (as my understanding, a `Comparator` which not follows the semantic
could result in such as unstable result/ dead loop/ wrong result, which depends
on how we used the `Comparator`)
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
