From ff72280c9ee35bf67c9b711837594fde29b86c4d Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 27 Mar 2008 19:06:14 +0000 Subject: [PATCH] When we have successfully optimized a MIN or MAX aggregate into an indexscan, the query result must be exactly one row (since we don't do this when there's any GROUP BY). Therefore 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, as seen in a bug report from Taiki Yamaguchi. We might need to work harder if we ever try to optimize grouped queries with this approach, but this solution will do for now. --- src/backend/optimizer/plan/planner.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 2f469bd924..6d6978dcf5 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.227 2008/03/18 22:04:14 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.228 2008/03/27 19:06:14 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -950,6 +950,17 @@ 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 {