[
https://issues.apache.org/jira/browse/PHOENIX-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940626#comment-14940626
]
Maryann Xue commented on PHOENIX-2270:
--------------------------------------
[~jamestaylor] Like your idea of perf measuring this, and we could probably
find out which cases may benefit from Phoenix partial sort and which may not,
and model the rels' cost accordingly.
> Implement Drill-specific rule for first level server-side sort
> --------------------------------------------------------------
>
> Key: PHOENIX-2270
> URL: https://issues.apache.org/jira/browse/PHOENIX-2270
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Labels: calcite, drill
>
> Phoenix should have a physical operator that executes a sort on the
> server-side which Drill can leverage when re-ordering is necessary. Unlike
> PHOENIX-2269 which is clearing going to be more efficient to let Phoenix
> handle, the sort is more of a gray area. Phoenix will be faster in the way it
> does the scan within the coprocessor, but it still needs to return the same
> number of rows. This process puts a pretty heavy burden on the region server
> as well. We should measure performance with and without Phoenix doing the
> sort. One potential scenario that may be a win for Phoenix is if the rows are
> already partially sorted and Phoenix can take advantage of this (which is not
> currently the case).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
