Re: query_id: jumble names of temp tables for better pg_stat_statement UX - Mailing list pgsql-hackers

From Tom Lane
Subject Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date
Msg-id 1831838.1742656359@sss.pgh.pa.us
Whole thread Raw
In response to Re: query_id: jumble names of temp tables for better pg_stat_statement UX  (Michael Paquier <michael@paquier.xyz>)
Responses Re: query_id: jumble names of temp tables for better pg_stat_statement UX
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Mar 22, 2025 at 10:43:00AM +0100, Christoph Berg wrote:
>> Are we at the point where the patch is already Ready for Committer?

> I'll think a bit more about how to document all that.  Anyway, yes,
> I'm OK with the per-field custom_query_jumble, so let's move on with
> that, so I will do something about that.

I'm not terribly happy with the entire proposal.

(1) I know it was asserted upthread that there was no performance
impact, but I find that hard to believe.

(2) This patch inserts catalog lookups into query ID computation,
which AFAIK there never were before.  This means you can't compute a
query ID outside a transaction or in an already-failed transaction.
Surely that's going to bite us eventually.

(3) I think having query jumbling work differently for temp tables
than other tables is a fundamentally bad idea.

So my feeling is: if we think this is the behavior we want, let's do
it across the board.  I suggest that we simply drop the relid from the
jumble and use the table alias (that is, eref->aliasname) instead.
ISTM this fits well with the general trend in pg_stat_statements
to merge statements together more aggressively than the original
concept envisioned.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Next commitfest app release is planned for March 18th
Next
From: Robert Haas
Date:
Subject: Re: making EXPLAIN extensible