From 78a9af1a27641ad983354bbaaaa4b7c00ea390f6 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Tue, 20 Sep 2022 09:13:49 +1200 Subject: [PATCH] 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.