mihaibudiu commented on code in PR #4147:
URL: https://github.com/apache/calcite/pull/4147#discussion_r1922734066
##########
core/src/test/resources/sql/sub-query.iq:
##########
@@ -1871,13 +1871,15 @@ select sal from "scott".emp e
(0 rows)
!ok
-EnumerableCalc(expr#0..4=[{inputs}], expr#5=[RAND()],
expr#6=[CAST($t5):INTEGER NOT NULL], expr#7=[2], expr#8=[MOD($t6, $t7)],
expr#9=[3], expr#10=[=($t8, $t9)], expr#11=[OR($t10, $t4)], SAL=[$t1],
$condition=[$t11])
- EnumerableMergeJoin(condition=[=($2, $3)], joinType=[left])
- EnumerableSort(sort0=[$2], dir0=[ASC])
- EnumerableCalc(expr#0..7=[{inputs}], EMPNO=[$t0], SAL=[$t5],
DEPTNO=[$t7])
- EnumerableTableScan(table=[[scott, EMP]])
- EnumerableCalc(expr#0..2=[{inputs}], expr#3=[false], DEPTNO=[$t0],
$f1=[$t3])
- EnumerableTableScan(table=[[scott, DEPT]])
+EnumerableCalc(expr#0..2=[{inputs}], expr#3=[RAND()],
expr#4=[CAST($t3):INTEGER NOT NULL], expr#5=[2], expr#6=[MOD($t4, $t5)],
expr#7=[3], expr#8=[=($t6, $t7)], expr#9=[OR($t8, $t2)], SAL=[$t0],
$condition=[$t9])
Review Comment:
I believe that correlated queries in general are much less efficient than
uncorrelated ones.
Moreover, the Calcite decorrelator can only decorrelate a limited number of
patterns.
That's why a decorrelated plan is preferred to a plan that has correlated
subqueries.
However, correctness is more important than performance, so we should take
this change if it fixes a correctness bug.
The question was whether we could have both correctness and performance, but
that can be part of a separate issue.
--
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]
