public inbox for [email protected]
help / color / mirror / Atom feedRe: 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]>
2026-01-11 10:12 ` Re: JumbleQuery ma treat different GROUP BY expr as the same Michael Paquier <[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-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 ` Re: JumbleQuery ma treat different GROUP BY expr as the same jian he <[email protected]>
2026-01-11 16:19 ` Re: JumbleQuery ma treat different GROUP BY expr as the same 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-10 16:46 Re: JumbleQuery ma treat different GROUP BY expr as the same Tom Lane <[email protected]>
2026-01-11 10:12 ` Re: JumbleQuery ma treat different GROUP BY expr as the same Michael Paquier <[email protected]>
@ 2026-01-11 12:11 ` jian he <[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-10 16:46 Re: JumbleQuery ma treat different GROUP BY expr as the same Tom Lane <[email protected]>
2026-01-11 10:12 ` Re: JumbleQuery ma treat different GROUP BY expr as the same Michael Paquier <[email protected]>
@ 2026-01-11 16:19 ` Tom Lane <[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