Re: pg_plan_advice: add NO_ scan and join method tags

From: Florin Irion <irionr(at)gmail(dot)com>
To: "Jonathan Gonzalez V(dot)" <jonathan(dot)abdiel(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, robertmhaas(at)gmail(dot)com
Subject: Re: pg_plan_advice: add NO_ scan and join method tags
Date: 2026-07-27 16:45:08
Message-ID: 9ba4c7da-06ee-4a5a-9479-9b1076cfc675@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On 14/07/2026 14:19, Jonathan Gonzalez V. wrote:
> I was trying to measure the test coverage of this patch and I found that
> the meson configuration wasn't updated, I think you're missing something
> like this:
>
> --- a/contrib/pg_plan_advice/meson.build
> +++ b/contrib/pg_plan_advice/meson.build
> @@ -57,6 +57,8 @@ tests += {
> 'gather',
> 'join_order',
> 'join_strategy',
> + 'no_join',
> + 'no_scan',
> 'partitionwise',
> 'prepared',
> 'scan',

Thanks for catching the meson.build gap — confirmed, no_join/no_scan
were added to the Makefile's REGRESS list but never mirrored into
meson.build. Fixed.

>
> After the tests run only two cases were not tested NO_MERGE_JOIN and
> NO_NESTED_LOOP, but these supposed to be tested, well I'll dig more on
> this one a second pass of the review.

On the coverage gap for NO_MERGE_JOIN/NO_NESTED_LOOP: I instrumented
both switch cases in pgpa_walker.c with log probes and reran no_join.sql
— both fire. Concretely: NO_NESTED_LOOP(f) (sql/no_join.sql:38) and the
stacked NO_HASH_JOIN(f) NO_NESTED_LOOP(f) case (line 52) both hit the
PGPA_TAG_NO_NESTED_LOOP case; NO_MERGE_JOIN(d) (line 45) hits
PGPA_TAG_NO_MERGE_JOIN. So ISTM the underlying advice-tag handling is
exercised.

>
> During the check, this came to my attention:
>
> + case PGPA_TAG_NO_INDEX_ONLY_SCAN:
> + return PGS_INDEXONLYSCAN | PGS_CONSIDER_INDEXONLY;
>
> Reading the comments I got this:
>
> When PGS_CONSIDER_INDEXONLY is
> unset, we don't even consider index-only scans, and any such scans that
> would have been generated become index scans instead. On the other hand,
> unsetting PGS_INDEXSCAN or PGS_INDEXONLYSCAN causes generated paths of the
> corresponding types to be marked as disabled.
>
> The message is a bit confusing but, I think that
> `PGS_INDEXONLY` should be the only option here? Otherwise, my
> understanding is that it will disable also PGS_INDEXSCAN, which is in
> the next line to be disable.

On PGS_CONSIDER_INDEXONLY: I think this traces back to the pathnodes.h
comment:

▎ When PGS_CONSIDER_INDEXONLY is unset, we don't even consider
index-only scans, and any such scans that would have been generated
become index scans instead. On the other hand, unsetting PGS_INDEXSCAN
or PGS_INDEXONLYSCAN causes generated paths of the corresponding types
to be marked as disabled.

That comment is actually describing the behavior we want.
NO_INDEX_ONLY_SCAN's mask clears PGS_INDEXONLYSCAN |
PGS_CONSIDER_INDEXONLY, leaving PGS_INDEXSCAN untouched. Per the
comment, clearing PGS_CONSIDER_INDEXONLY doesn't disable a path — it
changes what check_index_only() builds in the first place, converting
the would-be Index-Only Scan into a regular Index Scan path. Since we
never touch PGS_INDEXSCAN, that converted path stays enabled. Drop
PGS_CONSIDER_INDEXONLY from the mask (your suggestion) and
check_index_only() still returns true, so the planner builds an actual
(disabled) Index-Only Scan with no regular Index Scan alternative for
that index at all.

I confirmed this with the mask reduced to just PGS_INDEXONLYSCAN, the
no_scan test that expects NO_INDEX_ONLY_SCAN to fall back to a plain
Index Scan instead produced a Bitmap Heap Scan. So ISTM the current code
is correct.

attaching v3 with the meson.build change and rebased on current master.

Cheers,
Florin
---
www.enterprisedb.com

Attachment Content-Type Size
v3-0001-pg_plan_advice-Add-NO_SCAN-and-NO_JOIN_METHOD-tag.patch text/plain 54.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-07-27 17:06:20 Re: timestamp vs. timestamptz comparisons inconsistently ordered under DST
Previous Message Masahiko Sawada 2026-07-27 16:39:24 Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation