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 по дате отправления: