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

ASF GitHub Bot commented on PHOENIX-136:
----------------------------------------

Github user JamesRTaylor commented on a diff in the pull request:

    https://github.com/apache/incubator-phoenix/pull/31#discussion_r11862953
  
    --- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/SubselectRewriter.java ---
    @@ -0,0 +1,242 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + * http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +
    +package org.apache.phoenix.compile;
    +
    +import java.sql.SQLException;
    +import java.sql.SQLFeatureNotSupportedException;
    +import java.util.Arrays;
    +import java.util.HashMap;
    +import java.util.List;
    +import java.util.Map;
    +
    +import org.apache.phoenix.jdbc.PhoenixConnection;
    +import org.apache.phoenix.parse.AliasedNode;
    +import org.apache.phoenix.parse.ColumnParseNode;
    +import org.apache.phoenix.parse.DerivedTableNode;
    +import org.apache.phoenix.parse.HintNode;
    +import org.apache.phoenix.parse.LimitNode;
    +import org.apache.phoenix.parse.OrderByNode;
    +import org.apache.phoenix.parse.ParseNode;
    +import org.apache.phoenix.parse.ParseNodeRewriter;
    +import org.apache.phoenix.parse.SelectStatement;
    +import org.apache.phoenix.parse.TableNode;
    +import org.apache.phoenix.parse.TableWildcardParseNode;
    +import org.apache.phoenix.parse.WildcardParseNode;
    +import org.apache.phoenix.util.SchemaUtil;
    +
    +import com.google.common.collect.Lists;
    +
    +public class SubselectRewriter extends ParseNodeRewriter {
    +    private final String tableAlias;
    +    private final Map<String, ParseNode> aliasMap;
    +    
    +    public static SelectStatement applyPostFilters(SelectStatement 
statement, List<ParseNode> postFilters, String subqueryAlias) throws 
SQLException {
    +        if (postFilters.isEmpty())
    +            return statement;
    +        
    +        // TODO handle this from caller
    +        if (statement.getLimit() != null || (statement.isAggregate() && 
statement.getGroupBy().isEmpty()))
    --- End diff --
    
    Do you think it's feasible to do another set of changes for the compiler to 
handle the cases it can for derived tables and joins?


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

Reply via email to