[
https://issues.apache.org/jira/browse/CALCITE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643523#comment-14643523
]
Maryann Xue commented on CALCITE-818:
-------------------------------------
I think the unordered query case is exactly about the "top down" thing, the
consumer shouldn't have asked for a trait it does not need, i.e., unordered
queries should clear the collation trait when it realizes it does not need it.
> Multiple collation traits get wiped out when creating subset, thus cause
> unnecessary sort
> -----------------------------------------------------------------------------------------
>
> Key: CALCITE-818
> URL: https://issues.apache.org/jira/browse/CALCITE-818
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.4.0-incubating
> Reporter: Maryann Xue
> Assignee: Julian Hyde
> Priority: Minor
>
> "select p1 from (values (2, 1)) as t(p0, p1)"
> or
> "select p0+p1 from (values (2, 1)) as t(p0, p1)"
> would return a plan (with VolcanoPlanner) like:
> {code}
> EnumerableSort(...)
> EnumerableCalc(...)
> EnumerableValues(...)
> {code}
> It was because a multiple collation trait was inferred from the LogicalValues
> rel as: [[0,1], [1]], and the LogicalProject would have a corresponding
> collation trait based on the project expressions. But when optimizing, the
> multiple collation trait was simplified to empty when a subset for the
> LogicalValues rel was created, thus making EnumerableCalc unable to infer
> collation accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
