[jira] [Comment Edited] (PHOENIX-136) Support derived tables

["alex kamil (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955700#comment-13955700 ] 

alex kamil edited comment on PHOENIX-136 at 3/31/14 9:15 PM:
-------------------------------------------------------------

use case 1 (critical):  cc @maryannxue
SELECT a.col1, b.col2, c.col3 FROM 
(SELECT rk, col1 FROM table1 WHERE  col1 LIKE 'foo%' AND col300 IS NULL) AS a 
JOIN (SELECT rk, col2 FROM table2 WHERE  col2  LIKE 'bar%') AS b  ON a.rk=b.rk 
JOIN (SELECT rk, col3 FROM table3 ) AS c ON a.rk=c.rk;

nice to have: TPC-H queries with nested SELECT:  #2, 7, 9, 11,13,15-18,20-22 (http://www.tpc.org/tpch/spec/tpch2.16.0.pdf )

thanks!


was (Author: alexdl):
use case 1 (critical): 
SELECT a.col1, b.col2, c.col3 FROM 
(SELECT rk, col1 FROM table1 WHERE  col1 LIKE 'foo%' AND col300 IS NULL) AS a 
JOIN (SELECT rk, col2 FROM table2 WHERE  col2  LIKE 'bar%') AS b  ON a.rk=b.rk 
JOIN (SELECT rk, col3 FROM table3 ) AS c ON a.rk=c.rk;

nice to have: TPC-H queries with nested SELECT:  #2, 7, 9, 11,13,15-18,20-22 (http://www.tpc.org/tpch/spec/tpch2.16.0.pdf )

> Support derived tables
> ----------------------
>
>                 Key: PHOENIX-136
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-136
>             Project: Phoenix
>          Issue Type: Task
>            Reporter: James Taylor
>            Assignee: James Taylor
>              Labels: enhancement
>
> Add support for derived queries of the form:
> SELECT * FROM ( SELECT company, revenue FROM Company ORDER BY revenue) LIMIT 10
> Adding support for this requires a compile time change as well as a runtime execution change. The first version of the compile-time change could limit aggregation to only be allowed in the inner or the outer query, but not both. In this case, the inner and outer queries can be combined into a single query with the outer select becoming just a remapping of a subset of the projection from the inner select. The second version of the compile-time change could handle aggregation in the inner and outer select by performing client side (this is likely a less common scenario).
> For the runtime execution, change the UngroupedAggregateRegionObserver would be modified to look for a new "TopNLimit" attribute with an int value in the Scan. This would control the maximum number of values for the coprocessor to hold on to as the scan is performed. Then the GroupedAggregatingResultIterator would be modified to handle keeping the topN values received back from all the child iterators.



--
This message was sent by Atlassian JIRA
(v6.2#6252)