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

From Michael Paquier
Subject Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date
Msg-id aHbmsdI1k12yIFB2@paquier.xyz
Whole thread Raw
In response to Re: query_id: jumble names of temp tables for better pg_stat_statement UX  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses Re: query_id: jumble names of temp tables for better pg_stat_statement UX
List pgsql-hackers
On Tue, Jul 15, 2025 at 04:48:05PM +0200, Alexander Kukushkin wrote:
> I totally understand the wish to make pg_stat_statements useful for
> workloads that create/drop a ton of temporary tables.
> However, when pursuing this goal we impacted other types of totally valid
> workloads when tables with the same name exist in different schemas.
> Example:
> create schema s1;
> create table s1.t as select id from generate_series(1, 10) as id;
> create schema s2;
> create table s1.t as select id from generate_series(1, 1000000) as id;

I suspect that you mean s2.t and not s1.t here.

> select count(id) from s1.t;
> select count(id) from s2.t;
>
> That is, two different queries, accessing two absolutely different tables
> (one of them has 100000 times more rows!) were merged together.

Yes, we had this argument upthread, and it is still possible to
differentiate both cases by using a different alias in the FROM
clause, as of:
select count(id) from s1.t as t1;
select count(id) from s2.t as t2;

The new behavior where we do not need to worry about temporary tables,
which is not that uncommon because some workloads like using these for
JOIN patterns as a "temporary" anchor in a session, has more benefits
IMO, particularly more if the connections have a rather higher
turnover.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings
Next
From: Michael Paquier
Date:
Subject: Re: TOAST table vacuum truncation parameter inheritance bug (?) in autovacuum