diff options
| -rw-r--r-- | src/backend/optimizer/plan/planner.c | 13 |
1 files changed, 6 insertions, 7 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 73010f2f37a..b1c5a8cb131 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.161 2003/09/25 06:58:00 petere Exp $ + * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.161.2.1 2004/02/13 22:26:43 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -701,19 +701,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. |