[
https://issues.apache.org/jira/browse/HIVE-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041275#comment-16041275
]
Ashutosh Chauhan commented on HIVE-6348:
----------------------------------------
I am not sure doing it on AST is better (or easier). AST is not amenable to
traverse nor does it contain semantic info. Easier (and correct) way IMO would
be to write a rule on calcite operator tree which matches on HiveSort followed
by HiveSort check there is no limit in that sort and than removes that HiveSort
from tree.
SubQueryRemove rule will remove subqueries from tree by than, but I dont think
that will matter. Essentially, on an operator tree you are looking for
redundant Sort operators.
> Order by/Sort by in subquery
> ----------------------------
>
> Key: HIVE-6348
> URL: https://issues.apache.org/jira/browse/HIVE-6348
> Project: Hive
> Issue Type: Bug
> Reporter: Gunther Hagleitner
> Assignee: Rui Li
> Priority: Minor
> Labels: sub-query
> Attachments: HIVE-6348.1.patch, HIVE-6348.2.patch
>
>
> select * from (select * from foo order by c asc) bar order by c desc;
> in hive sorts the data set twice. The optimizer should probably remove any
> order by/sort by in the sub query unless you use 'limit '. Could even go so
> far as barring it at the semantic level.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
