rubenada commented on code in PR #4515:
URL: https://github.com/apache/calcite/pull/4515#discussion_r2313552002
##########
core/src/test/resources/sql/planner.iq:
##########
@@ -351,4 +351,179 @@ FROM "scott"."EMP";
!ok
+# [CALCITE-4617] Wrong offset when SortJoinTransposeRule pushes a Sort with an
offset
+select d.deptno, empno from "scott"."DEPT" d
+right join "scott"."EMP" e using (deptno) limit 10 offset 2;
++--------+-------+
+| DEPTNO | EMPNO |
++--------+-------+
+| 10 | 7934 |
+| 20 | 7369 |
+| 20 | 7566 |
+| 20 | 7788 |
+| 20 | 7876 |
+| 20 | 7902 |
+| 30 | 7499 |
+| 30 | 7521 |
+| 30 | 7654 |
+| 30 | 7698 |
++--------+-------+
+(10 rows)
+
+!ok
+EnumerableCalc(expr#0..2=[{inputs}], proj#0..1=[{exprs}])
+ EnumerableLimit(offset=[2], fetch=[10])
+ EnumerableHashJoin(condition=[=($0, $2)], joinType=[right])
+ EnumerableCalc(expr#0..2=[{inputs}], DEPTNO=[$t0])
+ EnumerableTableScan(table=[[scott, DEPT]])
+ EnumerableCalc(expr#0..7=[{inputs}], EMPNO=[$t0], DEPTNO=[$t7])
Review Comment:
ah, ok. It might be volcano, or it might be that the underlaying table has
already less than 12 rows...
Anyway, I think it's clearer this way (and we can see that the plan changes
but the result remains with vs without the rule), so I'd suggest to apply this
change to the test, please.
--
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]
