[
https://issues.apache.org/jira/browse/CALCITE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688926#comment-15688926
]
Julian Hyde commented on CALCITE-1498:
--------------------------------------
OK, I understand now. The "count-preserving" thing could be a future
enhancement. In the case that an input is count-preserving (which does not
happen often) we can push the limit and offset through, and remove them from
above the join.
> 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)
