[
https://issues.apache.org/jira/browse/CALCITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354170#comment-17354170
]
duan xiong commented on CALCITE-4617:
-------------------------------------
{code:java}
// ### [CALCITE-4617] Wrong offset when SortJoinTransposeRule pushes a sort
node with an offset
select d.deptno, empno
from "scott".dept d
right join "scott".emp e using (deptno)
order by empno limit 10 offset 1;
+--------+-------+
| DEPTNO | EMPNO |
+--------+-------+
| 30 | 7499 |
| 30 | 7521 |
| 20 | 7566 |
| 30 | 7654 |
| 30 | 7698 |
| 10 | 7782 |
| 20 | 7788 |
| 10 | 7839 |
| 30 | 7844 |
| 20 | 7876 |
+--------+-------+
(10 rows)
!ok
EnumerableCalc(expr#0..2=[{inputs}], proj#0..1=[{exprs}])
EnumerableLimit(offset=[1], fetch=[10])
EnumerableSort(sort0=[$1], dir0=[ASC])
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])
EnumerableLimit(fetch=[11])
EnumerableTableScan(table=[[scott, EMP]])
!plan
{code}
[~sylvaincrozon] Hi. This result is not valid. Because the table scott.emp
fetch 11 row not order by deptno ? This just get 11 rows in scott.emp, not
ensure this rows is 'top deptno 11'. or I misunderstood
> Wrong offset when SortJoinTransposeRule pushes a sort node with an offset
> -------------------------------------------------------------------------
>
> Key: CALCITE-4617
> URL: https://issues.apache.org/jira/browse/CALCITE-4617
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.26.0
> Reporter: Sylvain Crozon
> Assignee: Ruben Q L
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The SortJoinTransposeRule will push a sort node past a join, and then
> duplicate the sort node on top of the join. When the sort node has an offset,
> we should only apply it once, otherwise we end up skipping twice as many rows
> as we should. The sort node added on top of the join should have a null
> offset.
>
> For example the testSortJoinTranspose6 test checks that for this initial plan
> {code}
> LogicalProject(DEPTNO=[$0], EMPNO=[$2])
> LogicalSort(offset=[2], fetch=[10])
> LogicalJoin(condition=[=($0, $9)], joinType=[right])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> the SortJoinTransposeRule should convert to
> {code}
> LogicalProject(DEPTNO=[$0], EMPNO=[$2])
> LogicalSort(offset=[2], fetch=[10])
> LogicalJoin(condition=[=($0, $9)], joinType=[right])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalSort(offset=[2], fetch=[10])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> Which will result in applying the offset twice. Instead the LogicalSort on
> top of the join should just have a null offset
--
This message was sent by Atlassian Jira
(v8.3.4#803005)