MIME-Version: 1.0
References: <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CAKZiRmxtJAFG7e1+Vs9B8ngON=AOzJbuws+1ZeH4LsbJh5AzoQ@mail.gmail.com>
 <CA+TgmoY9Ne_Sh10u6LSPc3wvOQPLp3kF9nBp3nqJEG2JGF2QiA@mail.gmail.com>
 <CA+Tgmoa57S6mP=aTOXH2-gDAL4TMO1WbGgrHSg0s6J4zUH=04g@mail.gmail.com>
 <DEB1SAGVDX7S.JMV96X4R0RCS@gmail.com> <CA+Tgmoaf__2B0BUL+vrg28P+3buX=Ti-kybqkHiLTtFrrCfzuA@mail.gmail.com>
 <CA+TgmoYpcLNOuypOTdgCSLW7FuA=t6BtB3meTARHX2-Dj_81xQ@mail.gmail.com>
 <DEFNP3WX7BLX.1X7DS1P9X6JIF@nmfay.com> <CA+TgmoZjv9OyFu1Gkt78w0vWEti8S33w8trYHmErf-GMmGSi=w@mail.gmail.com>
 <DELPC4B56Y5A.3OBZ3WCH3T4VX@nmfay.com> <CA+TgmoaOSBQD9Ux4eG40w723ZN=c0J7p-+oX4+J8urUeyLMo5w@mail.gmail.com>
 <CAOYmi+=g+MMoOpWkk2weXWKJcKH0eKey8gKHHdH0dF4Tiawrhw@mail.gmail.com>
 <CA+TgmobwaT=PXPDDrgDup+jA8KHBbkxigtziD-zNzAKKkQYVgQ@mail.gmail.com>
 <CAOYmi+mOmEW=amDRQMfw6-Fb3ZmDEQFaJzwk8Bc8W8DzaP85XQ@mail.gmail.com>
 <CA+TgmoaX2AMW4cdFM3OngBJxmxpkdmzF33R7-CWhvRLfucbFMg@mail.gmail.com>
 <CAOYmi+njnRGcomnxTY6vsEW3wWigc0ruB0EyWFpb+PVVE8sWpw@mail.gmail.com>
 <CAOYmi+k4AyWCQHK=XVF99KVDuFkqxcADao61OWGLxu0nRYMONQ@mail.gmail.com>
 <CA+TgmoZ0x3ym_oueXRWzbM_=6ucKoPZVGj3rRMLBDC_FnetXDw@mail.gmail.com>
 <CAP53Pkycc=7N2bLzVT3x+qE1JamvRZWev5tFjdLJ1+-AV3Di+Q@mail.gmail.com> <CAP53PkxK=oeGySmq7AgN6pp8V0BEcuHY+d9xC640PxOT4QTUyQ@mail.gmail.com>
In-Reply-To: <CAP53PkxK=oeGySmq7AgN6pp8V0BEcuHY+d9xC640PxOT4QTUyQ@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 8 Jan 2026 11:07:31 -0500
Message-ID: <CA+Tgmob4PtUX=EVbhuQW8-zsmLzhyCnVwaLG71Gio=djK3Fu+g@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Lukas Fittl <lukas@fittl.com>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Dian Fay <di@nmfay.com>, 
	Matheus Alcantara <matheusssilv97@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmob4PtUX%3DEVbhuQW8-zsmLzhyCnVwaLG71Gio%3DdjK3Fu%2Bg%40mail.gmail.com>
Precedence: bulk

On Wed, Jan 7, 2026 at 2:04=E2=80=AFAM Lukas Fittl <lukas@fittl.com> wrote:
> That said, good news: After a bunch of iterations, I get a clean pass on =
the pg_hint_plan regression tests,
> whilst completely dropping its copying of core code and hackish re-run of=
 set_plain_rel_pathlist. See [0]
> for a draft PR (on my own fork of pg_hint_plan) with individual patches t=
hat explain some regression test
> differences.

That sounds AWESOME.

> The biggest change in the regression test output was due to how the "Para=
llel" hint worked in pg_hint_plan
> (basically it was setting parallel_*_cost to zero, and then messed with t=
he gucs that factor into
> compute_parallel_worker) -- I think the only sensible thing to do is to c=
hange that in pg_hint_plan, and
> instead rely on rejecting non-partial paths with PGS_CONSIDER_NONPARTIAL =
if "hard" enforcement of
> parallelism is requested. That caused some minor plan changes, but I thin=
k they can still be argued to be
> matching the user's intent of "make a scan involving this relation parall=
el".

Cool. I'm sort of curious what changed, but maybe it's not important
enough to spend time discussing right now.

> There were two bugs in 0004 that I had to fix to make this work:
>
> In cost_index, we are checking "path->path.parallel_workers =3D=3D 0", bu=
t parallel_workers only gets
> set later in the function, causing the PGS_CONSIDER_NONPARTIAL mask to no=
t be applied. Replacing
> this with checking the "partial_path" argument instead makes it work.

I agree that this is a bug. I'm thinking this might be the appropriate fix:

     enable_mask =3D (indexonly ? PGS_INDEXONLYSCAN : PGS_INDEXSCAN)
-        | (path->path.parallel_workers =3D=3D 0 ? PGS_CONSIDER_NONPARTIAL =
: 0);
+        | (partial_path ? 0 : PGS_CONSIDER_NONPARTIAL);

> In cost_samplescan, we set the PGS_CONSIDER_NONPARTIAL mask if its a non-=
partial path, but that
> causes Sample Scans to always be disabled when setting PGS_CONSIDER_NONPA=
RTIAL on the
> relation. I think we could simply drop that check, since we never generat=
e partial sample scan paths.

This one is less obvious to me. I mean, if PGS_CONSIDER_NONPARTIAL
lets us consider non-partial plans, and a sample scan is a non-partial
plan, then shouldn't the flag need to be set in order for us to
consider it? If not, maybe we need to rethink the name or the
semantics of that bit in some way.

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