amaliujia commented on a change in pull request #2107:
URL: https://github.com/apache/calcite/pull/2107#discussion_r474299358
##########
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:
Agreed. In fact, I am actually thinking this is a case of wrong plan
(more serious than a "concern"). Because for merge join implementation (not
only Enumerables but other system's implementation), I think assuming input is
sorted is reasonable. So for systems that only use Calcite as a planner, they
might see surprising plans
----------------------------------------------------------------
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]
