[
https://issues.apache.org/jira/browse/CALCITE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691304#comment-15691304
]
Maryann Xue commented on CALCITE-1498:
--------------------------------------
Yes, agree. In the query you pointed out plus one little change:
{code}
select d.deptno, empno
from sales.dept d
right join sales.emp e using (deptno)
order by e.deptno offset 1
{code}
We can actually push down the Sort node to "emp" side and remove the one above
the Join.
I will open another two JIRAs addressing the OFFSET bug and this potential
optimization.
> 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)
