mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-12 18:34:36 +08:00
Code Issues Packages Projects Releases Wiki Activity

Department of second thoughts: the rule that ORDER BY and DISTINCT are

Browse Source 
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.
This commit is contained in:
Tom Lane 2008-03-28 02:00:11 +00:00
parent 7692d8d5b7
commit 2e4094dad8
1 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
src/backend/optimizer/plan/planner.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.228 2008/03/27 19:06:14 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.229 2008/03/28 02:00:11 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -835,6 +835,21 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
MemSet(&agg_counts, 0, sizeof(AggClauseCounts));
/*
* If the query involves ungrouped aggregation, then it can produce
* at most one row, so we can ignore any ORDER BY or DISTINCT
* request. This isn't all that exciting as an optimization, but it
* prevents a corner case when optimize_minmax_aggregates succeeds:
* if ORDER BY or DISTINCT were present we'd try, and fail, to match
* the EquivalenceClasses we're about to build with the modified
* targetlist entries it will create.
*/
if (parse->hasAggs && parse->groupClause == NIL)
{
parse->sortClause = NIL;
parse->distinctClause = NIL;
}
/* Preprocess targetlist */
tlist = preprocess_targetlist(root, tlist);
@ -950,17 +965,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
* right tlist, and it has no sort order.
*/
current_pathkeys = NIL;
/*
* In fact, since we don't optimize grouped aggregates, it
* needs no sort order --- there must be exactly one output row,
* and so any ORDER BY or DISTINCT attached to the query is
* useless and can be dropped. Aside from saving useless cycles,
* this protects us against problems with matching the hacked-up
* tlist entries to sort clauses.
*/
Assert(!parse->groupClause);
parse->sortClause = NULL;
parse->distinctClause = NULL;
}
else
{