Re: query_id: jumble names of temp tables for better pg_stat_statement UX
| От | Alexander Kukushkin |
|---|---|
| Тема | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
| Дата | |
| Msg-id | CAFh8B=m5BPeo7vTYDSw2KV=CmjeATWGw-CHCZmJ+3ZKm7kVM1w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: query_id: jumble names of temp tables for better pg_stat_statement UX (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
On Wed, 16 Jul 2025 at 01:39, Michael Paquier <michael@paquier.xyz> wrote:
> 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.
Yes.
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.
Yes, I've seen this argument and know that aliases will make these queries look different.
However, we regularly hear from many different customers that they *don't control queries* sent by application or *can't modify these queries*.
Such kinds of workloads are also not that uncommon and this change makes it impossible to monitor them.
I would somewhat understand when a table in the query is used without specifying schema and such queries are merged together:
s1: SET search_path s1; select count(*) from t;
s2: SET search_path s2; select count(*) from t;
But, even this case doesn't feel right, because these tables are still different and therefore queries.
Regards,
--
Alexander Kukushkin
В списке pgsql-hackers по дате отправления: