[
https://issues.apache.org/jira/browse/CALCITE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643502#comment-14643502
]
Julian Hyde commented on CALCITE-818:
-------------------------------------
Is RemoveSortRule getting fired in this case? You are describing how the system
works "bottom up" and tries to describe, as best it can, the traits of each
relational expression. But it can also work "top down", where a consumer asks
for a producer with particular traits, and if it works (not proven!) then the
problems of the bottom-up approach will be rectified.
> 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)
