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

Maryann Xue commented on CALCITE-1498:
--------------------------------------

bq. In that query, neither side is count-preserving. So I don't think it's 
valid to push either LIMIT or OFFSET.
The rule works like this right now, which I'm point out is wrong.

The SortJoinTransposeRule does not really consider the "count-preserving" 
attribute. What it is trying to do is mainly to reduce the row count from the 
"outer" side relation, and it's definitely invalid to push the Sort node to the 
other child relation. Because whether a LIMIT or an OFFSET is pushed through 
onto the other side (dept side in the above RIGHT JOIN query), the join output 
row which is supposed to be eliminated will generate a null field instead.

> Avoid LIMIT with trivial ORDER BY being pushed through JOIN endlessly
> ---------------------------------------------------------------------
>
>                 Key: CALCITE-1498
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1498
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.10.0
>            Reporter: Maryann Xue
>            Assignee: Maryann Xue
>            Priority: Minor
>
> Currently LIMIT with trivial ORDER BY will be pushed through a JOIN endlessly 
> by SortJoinTransposeRule, because the method 
> {{RelMdUtil.checkInputForCollationAndLimit}} used to prevent endless matching 
> does not know that an sort on zero keys is trivially satisfied (without 
> requiring a Sort) by any relational expression:
> {code}
>     // Check if the input is already sorted
>     boolean alreadySorted = false;
>     if (!alreadySorted) {
>       for (RelCollation inputCollation : mq.collations(input)) {
>         if (inputCollation.satisfies(collation)) {
>           alreadySorted = true;
>           break;
>         }
>       }
>     }
> {code}
> if {{mq.collations(input)}} returns an empty array, {{alreadySorted}} will 
> always be false even if the required {{collation}} is an empty collation 
> (which indicates there's no need to sort). As a result, the check method 
> {{RelMdUtil.checkInputForCollationAndLimit}} will always return false and the 
> SortJoinTransposeRule will keep being fired endlessly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to