[
https://issues.apache.org/jira/browse/CALCITE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955325#comment-17955325
]
Zhen Chen commented on CALCITE-7047:
------------------------------------
Without this modification, two operators will be converted when there is only
limit, namely EnumerableLimitSort and EnumerableLimit. In theory, their costs
will be the same, resulting in unstable plans. The operator generated first
will be selected in the end (the execution result may not be wrong). So I
deliberately put EnumerableLimitSortRule in the front in the PR. Without this
modification, EnumerableLimit will not appear in the newly added case.
> Improve Sort parameter checking in EnumerableLimitSortRule
> ----------------------------------------------------------
>
> 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)
