[
https://issues.apache.org/jira/browse/CALCITE-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135874#comment-17135874
]
Haisheng Yuan commented on CALCITE-4058:
----------------------------------------
[~rubenql] I totally understand you concern.
Storing fetch and offset into sort is a great idea, but only for execution
engine. Because the engine can use heap sort to do partial sort, instead of
using quick sort (or other algorithms) to do the full sort, if the data can fit
into memory. In SQL Sever, there is a post-optimization step to rewrite LIMIT
on top of SORT into a SORT-N operator.
In Calcite's Enumerable convention, there is also a EnumerableLimit and
EnumerableLimitRule. But in logical optimization, I don't see any benefits to
putting all of them into a single Sort.
Breaking change or not or how breaking it is depends on how we modify it. If we
add a flag to disable the feature, down streams just need to specify the flag
value, without changing the code. However, breaking change should bot be the
excuse to stop improvement.
> Add Limit and LogicalLimit operator and deprecate limit in Sort
> ---------------------------------------------------------------
>
> Key: CALCITE-4058
> URL: https://issues.apache.org/jira/browse/CALCITE-4058
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> Add {{Limit}} base class and {{LogicalLimit}} operator.
> Fetch and offset should not be in Sort operator, we should deprecate the
> fields while keeping the Sort work for compatibility.
> {code:java}
> select * from foo limit 5 offset 3;
> select * from foo order by a;
> {code}
> The above 2 queries are totally different query, but have the same operators,
> SortxxxTranspose sometimes means limit push down, which is counter-intuitive.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
