Re: pg_plan_advice

On Thu, Jan 8, 2026 at 11:31 AM Lukas Fittl <lukas@fittl.com> wrote:
> In my assessment there were roughly four kinds of changes on the
> regression test outputs for pg_hint_plan:
>
> 1) The order of operations (e.g. whats the inner/outer rel in a
> parallel plan) - I think that's probably caused by the previous zero
> cost confusing the planner
> 2) The placement of the Gather node in the case of joins (its now on
> top of the join in more cases, vs below it) - I think that's also
> caused by the previous zero cost logic
> 3) Parallelism wasn't enforced before, but is enforced now (e.g.
> sequential scans on empty relations didn't get a Gather node
> previously)
> 4) Worker count changed because rel_parallel_workers is still limited
> by max_parallel_workers_per_gather, and so my patched version now sets
> that for the whole query to the highest of the workers requested in
> Parallel hints (vs before it was able to keep that to just what a plan
> node needed)

Ideally, if you say "hey, I want to use parallel query here," you
would get the best plan that the planner knows how to construct that
happens to use parallelism. #2 sounds to me like you weren't really
getting that, because you were making parallelism on cost rather than
disabling non-parallel paths. #3 also sounds that way, because you
asked for parallelism and didn't get it. So I would tend to view those
changes as improvements.

The others are a little trickier. I don't think I quite understand
what this patch changed with respect to #4. I'm guessing that maybe
what's happening here is that this isn't really due to anything in the
patch set, but is rather due to relying on pgs_mask rather than
copy-pasting lots of code, which maybe incidentally removed the
ability to tweak something that pg_hint_plan was previously tweaking.
Maybe you want to think about writing a patch to go with 0004 that
addresses that gap specifically?

I'm actually kind of surprised that you didn't run into a similar
problem with the Rows() hint, for which 0004 also doesn't provide
infrastructure. If there's no problem, cool, but if there's a problem
there you haven't detected yet, maybe we should try to plug that gap,
too.

I don't quite know what to say about #1. If your theory about it being
due to the zero costs is correct, that's another example of the
current implementation not really being able to achieve the ideal
behavior, and the patch making it better. If there's something else
going on there, then I don't know.

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