rubenada commented on a change in pull request #2107:
URL: https://github.com/apache/calcite/pull/2107#discussion_r474691265
##########
File path: core/src/test/resources/sql/sub-query.iq
##########
@@ -1761,9 +1761,10 @@ select sal from "scott".emp e
!ok
EnumerableCalc(expr#0..4=[{inputs}], expr#5=[NOT($t4)], expr#6=[IS NOT
NULL($t4)], expr#7=[OR($t5, $t6)], expr#8=[IS NOT TRUE($t7)], SAL=[$t1],
$condition=[$t8])
- EnumerableHashJoin(condition=[=($2, $3)], joinType=[left])
- EnumerableCalc(expr#0..7=[{inputs}], EMPNO=[$t0], SAL=[$t5], DEPTNO=[$t7])
- EnumerableTableScan(table=[[scott, EMP]])
+ EnumerableMergeJoin(condition=[=($2, $3)], joinType=[left])
Review comment:
I have looked in the debugger, and everything seems ok.
It seems that "scott" tables (like `scott.emp `and `scott.dep` in this
example) are already sorted by default by their keys (their Scan operator
contain already the trait Collation[0]).
Since Collation[0] is the required collation for the right input of this
EnumerableMergeJoin, there is no need to use a sort operator on the right.
However, since the left input requires Collation[2], an EnumerableSort is
required on the left.
----------------------------------------------------------------
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]
