Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 2e4094d

Browse files
committed
Department of second thoughts: the rule that ORDER BY and DISTINCT are
useless for an ungrouped-aggregate query holds regardless of whether optimize_minmax_aggregates succeeds. So we might as well apply the optimization in any case. I'll leave 8.3 as it was, since this version is a tad more invasive than my earlier patch.
1 parent 7692d8d commit 2e4094d

File tree

1 file changed

+16
-12
lines changed

1 file changed

+16
-12
lines changed

src/backend/optimizer/plan/planner.c

Lines changed: 16 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.228 2008/03/27 19:06:14 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.229 2008/03/28 02:00:11 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -835,6 +835,21 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
835835

836836
MemSet(&agg_counts, 0, sizeof(AggClauseCounts));
837837

838+
/*
839+
* If the query involves ungrouped aggregation, then it can produce
840+
* at most one row, so we can ignore any ORDER BY or DISTINCT
841+
* request. This isn't all that exciting as an optimization, but it
842+
* prevents a corner case when optimize_minmax_aggregates succeeds:
843+
* if ORDER BY or DISTINCT were present we'd try, and fail, to match
844+
* the EquivalenceClasses we're about to build with the modified
845+
* targetlist entries it will create.
846+
*/
847+
if (parse->hasAggs && parse->groupClause == NIL)
848+
{
849+
parse->sortClause = NIL;
850+
parse->distinctClause = NIL;
851+
}
852+
838853
/* Preprocess targetlist */
839854
tlist = preprocess_targetlist(root, tlist);
840855

@@ -950,17 +965,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
950965
* right tlist, and it has no sort order.
951966
*/
952967
current_pathkeys = NIL;
953-
/*
954-
* In fact, since we don't optimize grouped aggregates, it
955-
* needs no sort order --- there must be exactly one output row,
956-
* and so any ORDER BY or DISTINCT attached to the query is
957-
* useless and can be dropped. Aside from saving useless cycles,
958-
* this protects us against problems with matching the hacked-up
959-
* tlist entries to sort clauses.
960-
*/
961-
Assert(!parse->groupClause);
962-
parse->sortClause = NULL;
963-
parse->distinctClause = NULL;
964968
}
965969
else
966970
{

0 commit comments

Comments
 (0)