[jira] [Commented] (CALCITE-1508) SortJoinTransposeRule can remove the top Sort node if it is a trivial ORDER BY and the non-preserved side of the outer join is count-preserving

["Stamatis Zampetakis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646761#comment-16646761 ] 

Stamatis Zampetakis commented on CALCITE-1508:
----------------------------------------------

I think that the SortRemoveRule can eventually do it after the sort and limit are separated (e.g., in the EnumerableConvention). A limit operator may still remain in the plan but it should not impact a lot the performance. 

> SortJoinTransposeRule can remove the top Sort node if it is a trivial ORDER BY and the non-preserved side of the outer join is count-preserving
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-1508
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1508
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.10.0
>            Reporter: Maryann Xue
>            Assignee: Maryann Xue
>            Priority: Minor
>
> If the non-preserved side of the outer join is count-preserving, for each row from the preserved side, there can only be zero or one matches from the non-preserved side, which means the join can produce only one row. So it is safe to push a LIMIT and/or an OFFSET through, and meanwhile remove the original Sort node if it is a trivial ORDER-BY. For example,
> {code}
> select d.deptno, empno
>     from sales.dept d
>     right join sales.emp e using (deptno)
>     limit 10 offset 2
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)