Department of second thoughts: the rule that ORDER BY and DISTINCT are

useless for an ungrouped-aggregate query holds regardless of whether
optimize_minmax_aggregates succeeds.  So we might as well apply the
optimization in any case.

I'll leave 8.3 as it was, since this version is a tad more invasive
than my earlier patch.

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 6d6978dcf5bf616fc359284bdd51cd5cb74abe91..27d7b3dea26e6c80d03eb536360618b186b19fc7 100644 (file)
--- 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.228 2008/03/27 19:06:14 tgl Exp $
+ *   $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.229 2008/03/28 02:00:11 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -835,6 +835,21 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
 
        MemSet(&agg_counts, 0, sizeof(AggClauseCounts));
 
+       /*
+        * If the query involves ungrouped aggregation, then it can produce
+        * at most one row, so we can ignore any ORDER BY or DISTINCT
+        * request.  This isn't all that exciting as an optimization, but it
+        * prevents a corner case when optimize_minmax_aggregates succeeds:
+        * if ORDER BY or DISTINCT were present we'd try, and fail, to match
+        * the EquivalenceClasses we're about to build with the modified
+        * targetlist entries it will create.
+        */
+       if (parse->hasAggs && parse->groupClause == NIL)
+       {
+           parse->sortClause = NIL;
+           parse->distinctClause = NIL;
+       }
+
        /* Preprocess targetlist */
        tlist = preprocess_targetlist(root, tlist);
 
@@ -950,17 +965,6 @@ 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
        {