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