MIME-Version: 1.0
References: <19493-5878eac7a2525c23@postgresql.org>
 <2d59d7d6-6afe-4565-8ff7-ae764651589a@gmail.com>
 <ahY_s6GLOGoceXHT@paquier.xyz> <1779843554.737126560@fmail2.qdit>
 <418106.1779844099@sss.pgh.pa.us>
 <CAHewXNn7q9Bm=i=ZBMJxUsmFhavfdxwbwVzdhsV9uXZOk584HQ@mail.gmail.com>
 <CAHewXN=n_KzrOFgHyZwSHPuaXF-RRMig0o4yL+knoSE-_cMMPA@mail.gmail.com>
 <CAHewXNkHsjOjaWUcdtrGTWeHK8f1N8=L434O0b9ecgtGaMFQrg@mail.gmail.com>
 <CAJTYsWUsW6zm_5thDsmV=c9VLs-O==r1RusDDF7kCekV0AECDA@mail.gmail.com>
 <CAHewXNkVe1TQ1gi0_PzJhXw82AGK85Jc8+sLgC_CdtOzP_v+GA@mail.gmail.com>
In-Reply-To: 
 <CAHewXNkVe1TQ1gi0_PzJhXw82AGK85Jc8+sLgC_CdtOzP_v+GA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Fri, 29 May 2026 14:02:25 -0400
Message-ID: 
 <CA+TgmoZC23qe+-wWr0gjxU=4knqehX2-tZik=CR3tFXDuTiWxw@mail.gmail.com>
Subject: Re: BUG #19493: Assertion failure in pg_plan_advice with EXISTS
 subquery and DO_NOT_SCAN advice
To: Tender Wang <tndrwang@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>,
	Ayush Tiwari <ayushtiwari.slg01@gmail.com>,
	=?UTF-8?B?0JrQsNC70LjQvdC40L0g0J3QuNC60LjRgtCw?= <n.kalinin@postgrespro.ru>,
	Michael Paquier <michael@paquier.xyz>,
 Pierre Forstmann <pierre.forstmann@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoZC23qe%2B-wWr0gjxU%3D4knqehX2-tZik%3DCR3tFXDuTiWxw%40mail.gmail.com>
Precedence: bulk

On Thu, May 28, 2026 at 10:04=E2=80=AFPM Tender Wang <tndrwang@gmail.com> w=
rote:
> -- Tags like SEQ_SCAN and NO_GATHER don't allow sublists at all; other ta=
gs,
> -- except for JOIN_ORDER, allow at most one level of sublist. Hence, thes=
e
> -- examples should error out.
> "
> So 'DO_NOT_SCAN((x))' is valid syntax. The original codes in
> pgpa_build_trove() may
> forget about this case. I added this syntax case to the syntax.sql.
>
> I also added the query to scan.sql and adjusted the original comments.

Thanks for the analysis and the patch, but in fact DO_NOT_SCAN() was
intended to be a "simple" tag, not a "generic" one, and I just messed
up. This makes sense if you think through how it actually works. For a
tag like GATHER, GATHER((x y)) means something different form GATHER(x
y): the former means that there should be a Gather node on top of the
join between x and y, while the latter means that there should be two
separate Gather nodes, one atop x and the other atop y. On the other
hand, NO_GATHER(x y) means that no Gather node can appear anywhere
above x or y, and there is no such thing as NO_GATHER((x y)) because
it couldn't mean anything different. Likewise, SEQ_SCAN(x) means use a
sequential scan on x, and SEQ_SCAN((x)) or SEQ_SCAN((x y)) is refused
because you can't use a sequential scan on a group of tables.

Extending that reasoning to the current case, DO_NOT_SCAN() is like
SEQ_SCAN() or NO_GATHER(): it applies to a single relation, not to a
list of relations. However, for things to actually work that way,
pgpa_scanner.l needs to classify it as TOK_TAG_SIMPLE, and a
corresponding adjustment is needed in pgpa_parser.y. I overlooked the
need for this in the patch that introduced DO_NOT_SCAN.

I have committed a fix.

--=20
Robert Haas
EDB: http://www.enterprisedb.com