[
https://issues.apache.org/jira/browse/PHOENIX-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2270:
----------------------------------
Description: 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). (was: 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.)
> 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)
