You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@calcite.apache.org by GitBox <gi...@apache.org> on 2020/08/20 22:12:30 UTC

[GitHub] [calcite] amaliujia commented on a change in pull request #2107: [CALCITE-4113] Support LEFT join in EnumerableMergeJoin

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:
users@infra.apache.org