[jira] [Commented] (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=13955495#comment-13955495 ] 

alex kamil commented on PHOENIX-136:
------------------------------------

James, 

besides
GroupedAggregateRegionObserver, UngroupedAggregateRegionObserver, GroupedAggregatingResultIterator 

in what other key classes do you expect changes in order to support nested SELECT? 
I haven't done much work with hbase coprocesor api but I'll give it a shot as this issue became critical for us (the 'poor man' upsert select is not fast enough)

Thanks
Alex



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