[
https://issues.apache.org/jira/browse/CALCITE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17956216#comment-17956216
]
Zhen Chen commented on CALCITE-7047:
------------------------------------
[~nobigo] I found that no one has replied to this question yet. Can I change my
thinking. For example, implement an EnumerableTopN and EnumerableTopNRule to
supplement EnumerableLimit and EnumerableSort?
> Improve Volcano planner selection of sort conversion rules
> ----------------------------------------------------------
>
> Key: CALCITE-7047
> URL: https://issues.apache.org/jira/browse/CALCITE-7047
> Project: Calcite
> Issue Type: Bug
> Reporter: Zhen Chen
> Assignee: Zhen Chen
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.41.0
>
>
> In Calcite, there are three operators: {{{}EnumerableLimit{}}},
> {{{}EnumerableSort{}}}, and {{{}EnumerableLimitSort{}}}. Therefore, when
> converting {{LogicalSort}} to an {{Enumerable}} operator, the following logic
> applies:
> * If {{limit}} is not null and {{orderby}} is empty in {{{}Sort{}}}, it is
> converted to {{{}EnumerableLimit{}}}.
> * If {{limit}} is empty and {{orderby}} is not null in {{{}Sort{}}}, it is
> converted to {{{}EnumerableSort{}}}.
> * If both are not empty, it is converted to {{{}EnumerableLimitSort{}}}.
> Currently, the {{EnumerableLimitSortRule}} does not check these two
> properties and should be updated accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
