[ 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)