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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Дата
Msg-id aHbmsdI1k12yIFB2@paquier.xyz
обсуждение исходный текст
Ответ на Re: query_id: jumble names of temp tables for better pg_stat_statement UX  (Alexander Kukushkin <cyberdemn@gmail.com>)
Ответы Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Список 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

Вложения

В списке pgsql-hackers по дате отправления: