mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-30 19:00:29 +08:00
Code Issues Packages Projects Releases Wiki Activity

Repair optimization bug I introduced in a moment of brain fade back in

Browse Source 
Nov 2002: when constant-expression simplification removes all the
aggregate function calls from a query, that doesn't mean we can act as
though there never were any aggregates.  Per bug report from Gabor Szucs.
This commit is contained in:
Tom Lane 2004-02-13 22:26:30 +00:00
parent f884090371
commit 2e5fe483a3
1 changed files with 6 additions and 7 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.166 2004/02/03 17:34:03 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.167 2004/02/13 22:26:30 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -709,19 +709,18 @@ grouping_planner(Query *parse, double tuple_fraction)
/*
* Will need actual number of aggregates for estimating costs.
* Also, it's possible that optimization has eliminated all
* aggregates, and we may as well check for that here.
*
* Note: we do not attempt to detect duplicate aggregates here; a
* somewhat-overestimated count is okay for our present purposes.
*
* Note: think not that we can turn off hasAggs if we find no aggs.
* It is possible for constant-expression simplification to remove
* all explicit references to aggs, but we still have to follow the
* aggregate semantics (eg, producing only one output row).
*/
if (parse->hasAggs)
{
numAggs = count_agg_clause((Node *) tlist) +
count_agg_clause(parse->havingQual);
if (numAggs == 0)
parse->hasAggs = false;
}
/*
* Figure out whether we need a sorted result from query_planner.