From: David Rowley <drowley@postgresql.org>
Date: Mon, 19 Sep 2022 21:15:04 +0000 (+1200)
Subject: Fix out-dated comment in preprocess_groupclause()
X-Git-Tag: REL_15_RC1~38
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f6c70b81802a869303be9916d1a64a15f4dd29d1;p=thirdparty%2Fpostgresql.git

Fix out-dated comment in preprocess_groupclause()

The comment claimed we don't consider other orders of the GROUP BY clause,
but this is no longer true as of db0d67db2.

Discussion: https://postgr.es/m/CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.com
Backpatch-through: 15, where db0d67db2 was introduced.
---

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index a0f2390334e..d8e8f607b2b 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -2756,8 +2756,9 @@ remove_useless_groupby_columns(PlannerInfo *root)
  *
  * In principle it might be interesting to consider other orderings of the
  * GROUP BY elements, which could match the sort ordering of other
- * possible plans (eg an indexscan) and thereby reduce cost.  We don't
- * bother with that, though.  Hashed grouping will frequently win anyway.
+ * possible plans (eg an indexscan) and thereby reduce cost.  However, we
+ * don't yet have sufficient information to do that here, so that's left until
+ * later in planning.  See get_useful_group_keys_orderings().
  *
  * Note: we need no comparable processing of the distinctClause because
  * the parser already enforced that that matches ORDER BY.