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 по дате отправления: