[jira] [Updated] (PHOENIX-2270) Implement Drill-specific rule for first level server-side sort
[ 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)
[jira] [Updated] (PHOENIX-2270) Implement Drill-specific rule for first level server-side sort
[ https://issues.apache.org/jira/browse/PHOENIX-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-2270: -- Summary: Implement Drill-specific rule for first level server-side sort (was: Split sort into server-side partial sort and client-side merge 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 > > This has two parts: > 1. Model server-side partial sort and client-side merge sort as Phoenix > physical operators (rels). > 2. Split Phoenix ScanPlan and AggregatePlan with orderBy accordingly. > This might help PHOENIX-2262 too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2270) Implement Drill-specific rule for first level server-side sort
[ 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. (was: Phoenix should have a physical operator that executes a sort on the server-side which Drill can leverage when re-ordering is necessary. ) > 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2270) Implement Drill-specific rule for first level server-side sort
[ 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. (was: This has two parts: 1. Model server-side partial sort and client-side merge sort as Phoenix physical operators (rels). 2. Split Phoenix ScanPlan and AggregatePlan with orderBy accordingly. This might help PHOENIX-2262 too.) > 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)