Re: JumbleQuery ma treat different GROUP BY expr as the same
| От | Michael Paquier |
|---|---|
| Тема | Re: JumbleQuery ma treat different GROUP BY expr as the same |
| Дата | |
| Msg-id | aWN3nkHOSu392MFX@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: JumbleQuery ma treat different GROUP BY expr as the same (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: JumbleQuery ma treat different GROUP BY expr as the same
Re: JumbleQuery ma treat different GROUP BY expr as the same |
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: