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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Kukushkin <cyberdemn(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christoph Berg <myon(at)debian(dot)org>, Lukas Fittl <lukas(at)fittl(dot)com>, 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-07-15 23:39:29
Message-ID: aHbmsdI1k12yIFB2@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kiran K V 2025-07-16 00:53:49 Re: Query regarding support of test_decoding and PGReplicationStream with Standby Logical Replication
Previous Message Rich Shepard 2025-07-15 20:15:11 Re: Removing terminal period from varchar string in table column

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-07-15 23:48:37 Re: TOAST table vacuum truncation parameter inheritance bug (?) in autovacuum
Previous Message Peter Geoghegan 2025-07-15 23:30:21 Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings