phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-136) Support derived tables
Date Tue, 22 Apr 2014 14:56:18 GMT


ASF GitHub Bot commented on PHOENIX-136:

Github user maryannxue commented on a diff in the pull request:
    --- Diff: phoenix-core/src/main/java/org/apache/phoenix/compile/ ---
    @@ -290,6 +292,9 @@ protected BasicQueryPlan compileSingleQuery(StatementContext context,
             ColumnResolver resolver = context.getResolver();
             TableRef tableRef = context.getCurrentTable();
             PTable table = tableRef.getTable();
    +        if (table.getType() == PTableType.SUBQUERY)
    +            throw new SQLFeatureNotSupportedException("Complex nested queries not supported.");
    --- End diff --
    No, this is just subqueries (derived tables) in the from clause that SubselectRewriter
is unable to flatten. We don't have parser support for correlated subqueries so far.

> Support derived tables
> ----------------------
>                 Key: PHOENIX-136
>                 URL:
>             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

View raw message