Commit78a9af1

committed

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 ofdb0d67d.Discussion:https://postgr.es/m/CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.comBackpatch-through: 15, wheredb0d67d was introduced.

1 parent66fa8ff commit78a9af1Copy full SHA for 78a9af1

File tree

-2

lines changed

-2

lines changed

Lines changed: 3 additions & 2 deletions

Original file line number	Diff line number	Diff line change
`@@ -2758,8 +2758,9 @@ remove_useless_groupby_columns(PlannerInfo *root)`
`2758`	`2758`	`*`
`2759`	`2759`	`* In principle it might be interesting to consider other orderings of the`
`2760`	`2760`	`* GROUP BY elements, which could match the sort ordering of other`
`2761`		`- * possible plans (eg an indexscan) and thereby reduce cost. We don't`
`2762`		`- * bother with that, though. Hashed grouping will frequently win anyway.`
	`2761`	`+ * possible plans (eg an indexscan) and thereby reduce cost. However, we`
	`2762`	`+ * don't yet have sufficient information to do that here, so that's left until`
	`2763`	`+ * later in planning. See get_useful_group_keys_orderings().`
`2763`	`2764`	`*`
`2764`	`2765`	`* Note: we need no comparable processing of the distinctClause because`
`2765`	`2766`	`* the parser already enforced that that matches ORDER BY.`

Comments

(0)