public inbox for [email protected]help / color / mirror / Atom feed
Re: JumbleQuery ma treat different GROUP BY expr as the same 4+ messages / 3 participants [nested] [flat]
* Re: JumbleQuery ma treat different GROUP BY expr as the same @ 2026-01-10 16:46 Tom Lane <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Tom Lane @ 2026-01-10 16:46 UTC (permalink / raw) To: jian he <[email protected]>; +Cc: pgsql-hackers; Richard Guo <[email protected]> jian he <[email protected]> writes: > explain(costs off, verbose) select count(*) from t group by a; > explain(costs off, verbose) select count(*) from t group by b; > explain(costs off, verbose) select count(*) from t group by c; > JumbleQuery will jumble Query->groupClause, but RangeTblEntry->groupexprs in > Query->rtable is marked with query_jumble_ignore and therefore excluded from > jumbling. > So "group by a" and "group by" merged into the same entry in > pg_stat_statements, > Is this what we expected? 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. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: JumbleQuery ma treat different GROUP BY expr as the same @ 2026-01-11 10:12 Michael Paquier <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: Michael Paquier @ 2026-01-11 10:12 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers; Richard Guo <[email protected]> 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 Attachments: [application/pgp-signature] signature.asc (833B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: JumbleQuery ma treat different GROUP BY expr as the same @ 2026-01-11 12:11 jian he <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: jian he @ 2026-01-11 12:11 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers; Richard Guo <[email protected]> On Sun, Jan 11, 2026 at 6:13 PM Michael Paquier <[email protected]> wrote: > > 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 Sure, I will give it a try over the next few days. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: JumbleQuery ma treat different GROUP BY expr as the same @ 2026-01-11 16:19 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Tom Lane @ 2026-01-11 16:19 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers; Richard Guo <[email protected]> Michael Paquier <[email protected]> writes: > On Sat, Jan 10, 2026 at 11:46:27AM -0500, Tom Lane wrote: >> 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. I agree we should fix it in v18, but we really need to push to have the fix in 18.2 rather than delay longer. (IME, the .2 release is about when our more risk-averse users start to think about upgrading.) So there's a time limit on getting this done. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-01-11 16:19 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-10 16:46 Re: JumbleQuery ma treat different GROUP BY expr as the same Tom Lane <[email protected]> 2026-01-11 10:12 ` Michael Paquier <[email protected]> 2026-01-11 12:11 ` jian he <[email protected]> 2026-01-11 16:19 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox