Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit2e4094d

Browse files
committed
Department of second thoughts: the rule that ORDER BY and DISTINCT are
useless for an ungrouped-aggregate query holds regardless of whetheroptimize_minmax_aggregates succeeds. So we might as well apply theoptimization in any case.I'll leave 8.3 as it was, since this version is a tad more invasivethan my earlier patch.
1 parent7692d8d commit2e4094d

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)
[8]ページ先頭
©2009-2025 Movatter.jp