[
https://issues.apache.org/jira/browse/CALCITE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955330#comment-17955330
]
Zhen Chen commented on CALCITE-7047:
------------------------------------
Thanks, I will change the title later. This problem has been solved to a
certain extent. In fact, I developed this problem in another case. For example,
in the SQL select a from t order by a limit 5, if a itself is ordered, then
only EnumerableLimit is needed in the plan, and EnumerableLimitSort will also
be generated in the equivalent space. Although EnumerableLimitSort is
theoretically more expensive (because of the additional CPU cost of sorting),
the optimizer still selects EnumerableLimitSort. This is because the
VolcanoCost cost model only considers the number of rows, but model adjustment
will cause many cases to fail. So it may be necessary to evaluate the cost
model as a whole.
> 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)
