[
https://issues.apache.org/jira/browse/HIVE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668536#comment-13668536
]
Gopal V commented on HIVE-3562:
-------------------------------
I have implemented a similar fix as a Combiner in MR (LimitNKeys and
LimitNValues) instead of using a hash/heap in-memory.
This seems to be a lot more memory friendly since it doesn't need any extra
memory, but it doesn't help the speed of the sort operations as the data size
reduction is post-sort.
And since it works for any writable, it only needs a simple single class
implementation (no comparators within the combiner).
The combiner is only run if there are multiple spills, but if the combiner can
be forced by setting "min.num.spills.for.combine" = 0, then we can set a top-k
(unique keys/values) selection sort via "map.sort.class" config instead of the
default QuickSort impl, without any change to the hadoop core at all.
> Some limit can be pushed down to map stage
> ------------------------------------------
>
> Key: HIVE-3562
> URL: https://issues.apache.org/jira/browse/HIVE-3562
> Project: Hive
> Issue Type: Bug
> Reporter: Navis
> Assignee: Navis
> Priority: Trivial
> Attachments: HIVE-3562.D5967.1.patch, HIVE-3562.D5967.2.patch,
> HIVE-3562.D5967.3.patch, HIVE-3562.D5967.4.patch, HIVE-3562.D5967.5.patch
>
>
> Queries with limit clause (with reasonable number), for example
> {noformat}
> select * from src order by key limit 10;
> {noformat}
> makes operator tree,
> TS-SEL-RS-EXT-LIMIT-FS
> But LIMIT can be partially calculated in RS, reducing size of shuffling.
> TS-SEL-RS(TOP-N)-EXT-LIMIT-FS
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
