[
https://issues.apache.org/jira/browse/CALCITE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962348#comment-15962348
]
Gian Merlino edited comment on CALCITE-1719 at 4/10/17 2:54 AM:
----------------------------------------------------------------
[~julianhyde], the motivation for this rule is to make it possible for a query
tool to apply a limit on a user-entered query it doesn't understand, by
wrapping it in {{SELECT * FROM ( whatever ) LIMIT 10}}. That allows a query
tool to treat the user-entered query as an opaque string. The changes you're
suggesting would make a rule that is too narrow to be useful for this case.
So I have two lines of questions that I hope you can help with.
1. My reasoning with this rule is that it makes sense for SQL like {{SELECT *
FROM something LIMIT 10}} or even {{SELECT * FROM something}} (without the
limit) to yield a result that retains the same collation of the relation
{{something}}, whether that's a table or a subquery or what have you. Is that
line of reasoning bad?
2. Assuming this approach is a non starter, do you have any other ideas for the
original problem? (A query tool that wants to apply limits to queries it can't
parse.) It's possible for the tool to execute the original query and then stop
reading after a certain number of rows, but this solution isn't very satisfying
since it means the planner won't be aware of the limit and can't use it to
optimize execution.
was (Author: gian):
[~julianhyde], the motivation for this rule is to make it possible for a query
tool to apply a limit on a user-entered query it doesn't understand, by
wrapping it in {{SELECT * FROM ( whatever ) LIMIT 10}}. That allows a query
tool to treat the user-entered query as an opaque string. The changes you're
suggesting would make a rule that is too narrow to be useful for this case.
So I have two lines of questions that I hope you can help with.
1. My reasoning with this rule is that it makes sense for SQL like {{SELECT *
FROM something LIMIT 10}} or even {{SELECT * FROM something}} (without the
limit) to yield a result that retains the same collation of the relation
{{something}}, whether that's a table or a subquery or what have you. In other
words I think it makes sense for a Sort with no sort key to yield a result with
the same collation as its input. Is that line of reasoning bad?
2. Assuming this approach is a non starter, do you have any other ideas for the
original problem? (A query tool that wants to apply limits to queries it can't
parse.) It's possible for the tool to execute the original query and then stop
reading after a certain number of rows, but this solution isn't very satisfying
since it means the planner won't be aware of the limit and can't use it to
optimize execution.
> SortCollapseRule for collapsing nested sorts
> --------------------------------------------
>
> Key: CALCITE-1719
> URL: https://issues.apache.org/jira/browse/CALCITE-1719
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Gian Merlino
> Assignee: Julian Hyde
>
> Useful for subqueries like {{SELECT * FROM (...) LIMIT X}}, where the inner
> query might have an order by or limit.
> Patch in https://github.com/apache/calcite/pull/410.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
