[
https://issues.apache.org/jira/browse/CALCITE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955355#comment-17955355
]
Zhen Chen commented on CALCITE-7047:
------------------------------------
as [~nobigo] siad. TopN is the combination of EnumerableLimit and
EnumerableSort, while EnumerableLimitSort is a substitute for EnumerableLimit
and EnumerableSort. But I understand that ElementerableLimitSort should not be
a replacement, similar to TopN in other databases. So can anyone else give me
some advice whether this PR is necessary?
> 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)
