[
https://issues.apache.org/jira/browse/CALCITE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15685230#comment-15685230
]
Julian Hyde commented on CALCITE-1498:
--------------------------------------
Agreed, we can only push down LIMIT or OFFSET to the "count-preserving" side. I
think we already do that properly. We just shouldn't worry about whether the
order of the rows is deterministic; that's the user's problem.
> Allow LIMIT with trivial ORDER BY to be pushed through JOIN
> -----------------------------------------------------------
>
> 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
>
> Allow LIMIT with trivial ORDER BY to be pushed through a JOIN that does not
> affect the number of rows. Currently it cannot, because
> {{RelMdUtil.checkInputForCollationAndLimit}} 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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
