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

From Lukas Fittl
Subject Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date
Msg-id CAP53PkzAPrHNHquT76mVjfStrz0B2hKhF+CbAZ_w9QJUJ_1oJQ@mail.gmail.com
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
Re: query_id: jumble names of temp tables for better pg_stat_statement UX
List pgsql-hackers
On Mon, Mar 24, 2025 at 8:51 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > select * from foo s1;
> > select * from foo s2;
>
> ah, thanks for pointing this out. Not as good of a workaround as
> a comment since one must change aliases, but at least there is
> a workaround...

Exactly.  Like Tom I'm not really worried about the proposal, but of
course I could prove to be wrong.  I am ready to assume that bloat in
pgss entries caused by temp tables is a more common case.

For what its worth, +1 on the current proposal in this thread (and doing it without a GUC), i.e. merging a query that references the same table alias, ignoring different schemas.

In the context of the earlier referenced one-schema-per-customer workloads:

In my experience these often not work well with pg_stat_statements today because of their own bloat problem, just like with temp tables. You quickly have way too many unique entries, and your query text file accumulates a lot of duplicative entries (since the same query text gets repeated in the text file, since its queryid is different), to the point that you can't monitor your workload at all anymore.

Thanks,
Lukas

--
Lukas Fittl

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: Alena Rybakina
Date:
Subject: Re: Vacuum statistics