On Wed, 16 Jul 2025 at 01:39, Michael Paquier <mich...@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
