Re: query_id: jumble names of temp tables for better pg_stat_statement UX

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, ma lz <ma100(at)hotmail(dot)com>
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date: 2025-03-25 14:59:34
Message-ID: CAA5RZ0u7cV1gi_JSXKQ_yJD6FHBT3o9jrkp1rTgtcM-HPQJW8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> 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.

That is true in terms of pg_stat_statements, and I have seen users
have to increase
pg_stat_statements.max to something much higher to avoid the bloat and constant
deallocs/GC.

But, besides pg_stat_statements, queryId is used to group queries for
database load
monitoring ( pg_stat_activity sampling). As of now, different schemas
are tracked
separately, but with this change they will be merged. This may come as
a surprise to
use-cases that rely on the existing behavior.

But I do agree that pg_s_s bloat is a big pain point, so this change
should be positive
overall. Let's see if there are enough complaints to force us to reconsider.

--
Sami Imseih
Amazon Web Services (AwS)

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2025-03-25 15:27:13 Re: Experience and feedback on pg_restore --data-only
Previous Message Alexander Farber 2025-03-25 10:39:03 How to pass a list of locations (longitude, latitude) to a PostgreSQL/PostGIS stored function?

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-03-25 15:26:14 Re: AIO v2.5
Previous Message Nathan Bossart 2025-03-25 14:57:46 Re: vacuum_truncate configuration parameter and isset_offset