Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4cLC-007HL6-0B for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Sep 2026 10:49:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x4cL9-004W3p-2g for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Sep 2026 10:49:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4cJk-004Gca-0G for pgsql-hackers@lists.postgresql.org; Thu, 10 Sep 2026 10:47:44 +0000 Received: from s99.boros.hosting ([2a00:1630:14d:0:213:163:93:248]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x4bNn-00000004vmE-0YdS for pgsql-hackers@lists.postgresql.org; Thu, 10 Sep 2026 09:47:52 +0000 Received: from s99.boros.hosting (localhost.localdomain [127.0.0.1]) by s99.boros.hosting (Postfix) with ESMTP id 7F8F36E070A for ; Thu, 10 Sep 2026 11:47:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-9999 required=3 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: s99.boros.hosting (amavis) (amavisd-new); dkim=pass (1024-bit key) header.d=database.one Received: from s99.boros.hosting ([213.163.93.248]) by s99.boros.hosting (s99.boros.hosting [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aVBcYxOiFw1 for ; Thu, 10 Sep 2026 11:47:43 +0200 (CEST) Received: from smtpclient.apple (92-68-31-37.biz.kpn.net [92.68.31.37]) by s99.boros.hosting (Postfix) with ESMTPSA id B06996E0605 for ; Thu, 10 Sep 2026 11:47:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=database.one; s=default; t=1789033662; bh=/HBcaS8XDbe4moTANeIP50A/lW9gQK/y37sisLoTPjY=; h=From:Subject:To; b=OWd6t19rWGIG7AN1P1rpQKpZrAKjJ0ejl61PzhxIBeW9eohZkGbG+FMSKGhMd+KtS r+KU/NDjhnUleVxVHcE+pn5bPeRToU1h00m4DJ3U4RvqB904m28DnKoqVQoKPuJiTJ dQ687GvlF2W8iwJqOqRF6uRH9aQpoSIcLivpttp4= Authentication-Results: s99.boros.hosting; spf=pass (sender IP is 92.68.31.37) smtp.mailfrom=lists@database.one smtp.helo=smtpclient.apple Received-SPF: pass (s99.boros.hosting: connection is authenticated) From: mailinglists Content-Type: multipart/alternative; boundary="Apple-Mail=_9DF280E6-D390-4D1F-885A-50A5CAE3FADD" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\)) Subject: unexpected behaviour generating queryid Date: Thu, 10 Sep 2026 11:47:31 +0200 References: To: pgsql-hackers@lists.postgresql.org In-Reply-To: Message-Id: <9E79BFEC-0A4D-4DBC-BE5E-624AF6BF0844@database.one> X-Mailer: Apple Mail (2.3864.700.51.1.1) X-PPP-Message-ID: <178903366289.3710577.318063191310133880@s99.boros.hosting> X-PPP-Vhost: database.one List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_9DF280E6-D390-4D1F-885A-50A5CAE3FADD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Something has changed along the line, possibly already in PG17, in the = way query=E2=80=99s are generated that makes it possible for queryid=E2=80= =99s to clash.=20 The crux of the issue seems to be that tables are now identified by = their alias, and only their alias, no longer their old. This may become especially problematic with the upcoming plan_advice = extension, since that relies completely on the queryid. I prepared a small example that shows a clash.=20 I am assuming that the compute_query_id is on auto. select * from pg_settings where name like '%compute%'; =E2=80=94 setup test tables=20 drop table if exists test_measurements; create table test_measurements ( id serial primary key, name text, measurement_ts timestamptz default now(), value float ); drop table if exists test_users; create table test_users ( id int, fullname text, address text, creation_moment timestamptz default now() ); insert into test_measurements (name, measurement_ts, value) select 'voltage' name, now() - interval '1 minute'*n measurement_ts, floor(random()*100) + n value from generate_series(1,1000) n; insert into test_users (id, fullname, address, creation_moment) values (0,'backend', 'Office 69', '2026-01-01 00:00:00+00'::timestamptz) , (1,'root', 'Office 69', '2026-01-02 10:10:10+00'::timestamptz); -- testing queries explain verbose select * from test_measurements a where id IN (66, 77, = 88, 99); explain verbose select * from test_users a where id IN (0, 1); explain verbose select * from test_measurements xx where id IN (66, 77, = 88, 99); The first two queries give me an identical queryid. Tested on PG19Beta3 Ellert.= --Apple-Mail=_9DF280E6-D390-4D1F-885A-50A5CAE3FADD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Something has changed along the line, = possibly already in PG17, in the way query=E2=80=99s are generated that = makes it possible for queryid=E2=80=99s to clash. 
The crux of = the issue seems to be that tables are now identified by their alias, and = only their alias, no longer their old.
This may become especially = problematic with the upcoming plan_advice extension, since that relies = completely on the queryid.

I prepared a small = example that shows a clash. 
I am assuming that the = compute_query_id is on auto.
select * from pg_settings where name like '%compute%';
=E2=80=94 setup test tables =

drop table if exists test_measurements;
create table test_measurements =
(
  =
  id serial primary key,
    name text,
    =
measurement_ts timestamptz default now(),
    value =
float
);
drop table if exists test_users;
create table =
test_users (
    =
id int,
    fullname =
text,
    address text,
    =
creation_moment timestamptz default now()
);
insert into =
test_measurements (name, measurement_ts, value)
select 'voltage' =
name,
        now() - interval '1 =
minute'*n measurement_ts,
        floor(random()*100) + n  value
from =
generate_series(1,1000) n;

insert into test_users (id, fullname, address, creation_moment)
values (0,'backend', 'Office 69', '2026-01-01 =
00:00:00+00'::timestamptz)
     , (1,'root', 'Office 69', '2026-01-02 =
10:10:10+00'::timestamptz);

-- testing queries
explain =
verbose select * from test_measurements a where id IN (66, 77, 88, 99);
explain verbose select * =
from test_users a where id IN (0, 1);
explain verbose select * from test_measurements xx where id IN (66, 77, 88, 99);
The first two queries = give me an identical queryid.
Tested on = PG19Beta3

Ellert.
= --Apple-Mail=_9DF280E6-D390-4D1F-885A-50A5CAE3FADD--