On Sat, Jan 10, 2026 at 11:46:27AM -0500, Tom Lane wrote: > It is not what happened before we invented RTE_GROUP. I tried your > experiment in v14 and got: > > regression=# SELECT calls, rows, query FROM pg_stat_statements ORDER BY query > COLLATE "C"; > calls | rows | query > -------+------+--------------------------------------------------------------- > 1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t > 1 | 0 | explain(costs off, verbose) select count(*) from t group by a > 1 | 0 | explain(costs off, verbose) select count(*) from t group by b > 1 | 0 | explain(costs off, verbose) select count(*) from t group by c > (4 rows) > > So I'm inclined to think this was an unintentional change of behavior.
The difference of behavior is between v17 and v18, as an effect of 247dea89f761. I know that we should not break query ID computations in stable branches, but v18 is very recent and we still have many years to support it.. So I would like to suggest that we make an exception and backpatch a fix to v18. This behavior is not cool for users. This issue also points to a gap in the regression of pg_stat_statements, where we have never bothered testing patterns of GROUP BY with the same table and different attributes. Jian, would you like to write a patch? -- Michael
signature.asc
Description: PGP signature
