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