[ https://issues.apache.org/jira/browse/HIVE-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13743866#comment-13743866 ]
Gopal V commented on HIVE-5093: ------------------------------- [~thejas] You are right, the systems slows down & adds another 3 seconds when the combiner is not actually doing anything useful (i.e limit > row count). But the use-case of LIMIT <human-number> queries used in analytics is common enough for this to be worthwhile. If this is saving time, the next step is to use a O(n + k*lg(k)) quick-select with a limit-k instead of quick-sort as the map sort class & get away from sorting it as well. Particularly if k is so much smaller than n, which is an easy decision at the partition phase in the indexed sorter. > Use a combiner for LIMIT with GROUP BY and ORDER BY operators > ------------------------------------------------------------- > > Key: HIVE-5093 > URL: https://issues.apache.org/jira/browse/HIVE-5093 > Project: Hive > Issue Type: Bug > Components: Query Processor > Affects Versions: 0.12.0 > Reporter: Gopal V > Assignee: Gopal V > Attachments: HIVE-5093-WIP-01.patch > > > Operator trees of the following structure can have a memory friendly combiner > put in place after the sort-phase > "GBY-LIM" and "OBY-LIM" > This will cut down on I/O when spilling to disk and particularly during the > merge phase of the reducer. > There are two possible combiners - LimitNKeysCombiner and > LimitNValuesCombiner. > The first one would be ideal for the GROUP-BY case, while the latter would > more useful for the ORDER-BY case. > The combiners are still relevant even if there are 1:1 forward operators on > the reducer side and for small data items, the MR base layer does not run the > combiners at all. -- 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