Re: BUG #19493: Assertion failure in pg_plan_advice with EXISTS subquery and DO_NOT_SCAN advice

On Thu, May 28, 2026 at 10:04 PM Tender Wang <tndrwang@gmail.com> wrote:
> -- Tags like SEQ_SCAN and NO_GATHER don't allow sublists at all; other tags,
> -- except for JOIN_ORDER, allow at most one level of sublist. Hence, these
> -- 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.

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