postgres.git / summary / log / commit / refs

commit    78a9af1a27641ad983354bbaaaa4b7c00ea390f6
Author:   David Rowley <drowley@postgresql.org>
Date:     Mon Sep 19 21:13:49 2022 +0000
First released in: 16.0, 15.0

    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.


 src/backend/optimizer/plan/planner.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 079bd0bfdfd..c0bdc77d390 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -2758,8 +2758,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.


[parent: 66fa8ff63798]