From f6c70b81802a869303be9916d1a64a15f4dd29d1 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Tue, 20 Sep 2022 09:15:04 +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 a0f2390334..d8e8f607b2 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.