1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

When we have successfully optimized a MIN or MAX aggregate into an indexscan,

Browse Source 
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.
This commit is contained in:
Tom Lane 2008-03-27 19:06:23 +00:00
parent 1c0e618e17
commit 707867e9fd
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226 2008/01/01 19:45:50 momjian Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226.2.1 2008/03/27 19:06:23 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -943,6 +943,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
{