public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Kukushkin <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Lukas Fittl <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: ma lz <[email protected]>
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date: Wed, 16 Jul 2025 08:20:39 +0200
Message-ID: <CAFh8B=m5BPeo7vTYDSw2KV=CmjeATWGw-CHCZmJ+3ZKm7kVM1w@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAFh8B==vog16UGpigF5jukg0yZW+MHsvvKG0QBs7gV6cHgqanA@mail.gmail.com>
<[email protected]>
On Wed, 16 Jul 2025 at 01:39, Michael Paquier <[email protected]> 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
view thread (4+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX
In-Reply-To: <CAFh8B=m5BPeo7vTYDSw2KV=CmjeATWGw-CHCZmJ+3ZKm7kVM1w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox