[
https://issues.apache.org/jira/browse/CALCITE-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136184#comment-17136184
]
Haisheng Yuan commented on CALCITE-4058:
----------------------------------------
Hi [~julianhyde], thanks for commenting.
{quote}
So your operator ends up with fields {{fetch}}, {{offset}}, {{collation}} - the
exact same fields that {{Sort}} has today.
{quote}
As you pointed out, that is exactly what I have in mind. I am not saying Sort
is not capable of doing all the work, but the opposite, it is doing too much,
hence cause confusion. With the proposal, Only \{{ORDER BY}} should be
translated to LogicalSort or or just use root collation requirement. \{{ORDER
BY LIMIT OFFSET}} or \{{LIMIT OFFSET}} should be translated to LogicalLimit.
{quote}
But the cost is to add one extra operator to our core set of operators. That is
something we should not do lightly. Increasing a matrix from size N to N+1 adds
2N to the number of pairwise combinations.
{quote}
I don't see it adds 2N combinations. As far as I can see, we just need to add
similar rules with SortJoinTransposeRule, SortProjectTransposeRule,
SortUnionTransposeRule, SORT_FETCH_ZERO_INSTANCE, and update metadata handler
to process Limit.
{quote}
In this case, because of the similarity between {{Sort}} and {{Limit}} at both
logical and physical levels.
{quote}
Why do we have \{{EnumerableLimit}}? What is the similarity between
{code:java}
select * from foo order by a;
{code}
and
{code:java}
select * from foo limit 10;{code}
If they are similar, why do we need the isPureLimit and isPureOrder?
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/RelOptUtil.java#L170]
If there are downstream projects create their own limit operators, does that
mean it is something that worth considering?
[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillLimitRel.java]
[https://github.com/VoltDB/voltdb/blob/master/src/frontend/org/voltdb/plannerv2/rel/logical/VoltLogicalLimit.java]
> 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)
