[
https://issues.apache.org/jira/browse/CALCITE-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136230#comment-17136230
]
Julian Hyde commented on CALCITE-4058:
--------------------------------------
bq. Why do we have EnumerableLimit?
Because it's an algorithm. There are many possible algorithms for each logical
operator. Algorithms often rely on the physical properties of their input.
bq. What is the similarity between ...
They are similar enough. {{Sort}} an empty collation (zero sort keys) is a
degenerate case but it fits naturally enough with other cases. (It is less
troublesome, in fact, than {{Aggregate}} with zero keys.)
You may say that limit with zero sort keys is not deterministic. But many other
limits are not deterministic, e.g. "select * from emp order by deptno limit
10".
bq. If there are downstream projects create their own limit operators, does
that mean it is something that worth considering?
We could consider adding a base class. But they are just algorithms. Adding
{{LogicalLimit}} as one of the core operators is different thing, and I don't
agree with it.
> 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)
