Github user comnetwork commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/314#discussion_r206382301
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/compile/QueryCompiler.java ---
@@ -559,8 +559,16 @@ protected QueryPlan
compileSingleFlatQuery(StatementContext context, SelectState
groupBy = groupBy.compile(context, innerPlanTupleProjector);
context.setResolver(resolver); // recover resolver
RowProjector projector = ProjectionCompiler.compile(context,
select, groupBy, asSubquery ? Collections.<PDatum>emptyList() : targetColumns,
where);
- OrderBy orderBy = OrderByCompiler.compile(context, select,
groupBy, limit, offset, projector,
- groupBy == GroupBy.EMPTY_GROUP_BY ?
innerPlanTupleProjector : null, isInRowKeyOrder);
+ OrderBy orderBy = OrderByCompiler.compile(
+ context,
+ select,
+ groupBy,
+ limit,
+ offset,
+ projector,
+ groupBy == GroupBy.EMPTY_GROUP_BY ?
innerPlanTupleProjector : null,
+ groupBy == GroupBy.EMPTY_GROUP_BY ? isInRowKeyOrder : true,
+ where);
--- End diff --
@maryannxue , yes, you are right , Eliminating order-by based on the inner
plan ordering is ultimate solution. Openning this JIRA is just to optimize the
OrderBy for ClientAggregatePlan when there is a GroupBy, it is only to need to
conside the GroupBy of the outer query, and innerQuery is not required to take
into account. It is much simpler than purely optimizing OrderBy for
ClientScanPlan, which need to make a huge modification and refactor with
OrderByCompiler and OrderPreservingTracker. I have planned to purely optimize
OrderBy for ClientScanPlan after this JIRA by openning a new JIRA.
---
