Horton
Menu

Re: pg_plan_advice

Lukas Fittl <lukas@fittl.com>

View thread
From: Lukas Fittl <lukas@fittl.com>
To: Robert Haas <robertmhaas@gmail.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>
Date: 2026-01-08T20:47:05Z
Lists: pgsql-hackers 
On Thu, Jan 8, 2026 at 11:37 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

Agreed from my perspective.

> 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?

Yeah, I don't think this needs to be reviewed in detail here now, but
I do think there is a potential to improve worker count overrides in
core code. I agree this can be done as a follow-up to 0004 - and I
don't have a good sense yet for how infrastructure for this could look
like.

pg_hint_plan has some existing logic to copy parallel worker counts
into other paths (e.g. for joins), and I kept that for now in that
draft patch [0] to reduce further test output differences.

> 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.

Yeah, 0004 doesn't provide infrastructure for that directly. However,
it does add joinrel_setup_hook which enables modifying joinrel->rows
at the right time without copying core code. Previously pg_hint_plan
modified the row estimates for joins through copied core code [1], but
0004 lets it affect join rels through the new hook [2].

> 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.

Yeah, I don't think we need to worry about this in the context of
applying 0004, and its something that Michael or other pg_hint_plan
maintainers can assess when updating it.

Its worth noting for clarity, whilst 0004 requires extensions that
modify certain GUCs during the planning process to instead use the PGS
mask, max_parallel_workers_per_gather is not one of these GUCs. I was
driven to also do the parallel hint changes because I wanted to prove
that pg_hint_plan can now function without any copying of core code,
but technically all the parallel regression test changes can be
avoided when keeping the prior zero parallel_*_cost mechanism +
modifying max_parallel_workers_per_gather during planning as before,
whilst still updating the scan/join hints to use the PGS mask logic.

Thanks,
Lukas

[0]: https://github.com/lfittl/pg_hint_plan/blob/postgres-19-with-plan-generation-strategies/pg_hint_plan.c#L4602
[1]: https://github.com/ossc-db/pg_hint_plan/blob/master/make_join_rel.c#L126
[2]: https://github.com/lfittl/pg_hint_plan/blob/postgres-19-with-plan-generation-strategies/pg_hint_plan.c#L4372

-- 
Lukas Fittl

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_plan_advice: Fix another unique-semijoin bug.

  2. pg_plan_advice: Export feedback-related definitions.

  3. pg_plan_advice: Fix a bug when a subquery is pruned away entirely.

  4. pg_plan_advice: Add alternatives test to Makefile.

  5. pg_plan_advice: Handle non-repeatable TABLESAMPLE scans.

  6. pg_stash_advice: Allow stashed advice to be persisted to disk.

  7. Add pg_stash_advice contrib module.

  8. pg_plan_advice: Avoid assertion failure with partitionwise aggregate.

  9. pg_plan_advice: Invent DO_NOT_SCAN(relation_identifier).

  10. Add an alternative_plan_name field to PlannerInfo.

  11. pg_plan_advice: Refactor to invent pgpa_planner_info

  12. Respect disabled_nodes in fix_alternative_subplan.

  13. get_memoize_path: Don't exit quickly when PGS_NESTLOOP_PLAIN is unset.

  14. test_plan_advice: Set TAP test priority 50 in meson.build.

  15. pg_plan_advice: Avoid a crash under GEQO.

  16. Test pg_plan_advice using a new test_plan_advice module.

  17. pg_plan_advice: Always install pg_plan_advice.h, and in the right place

  18. pg_plan_advice: Fix failures to accept identifier keywords.

  19. Add pg_plan_advice contrib module.

  20. Allow extensions to mark an individual index as disabled.

  21. Replace get_relation_info_hook with build_simple_rel_hook.

  22. Store information about Append node consolidation in the final plan.

  23. Store information about elided nodes in the final plan.

  24. Store information about range-table flattening in the final plan.

  25. Pass cursorOptions to planner_setup_hook.

  26. Fix PGS_CONSIDER_NONPARTIAL interaction with Materialize nodes.

  27. Fix mistakes in commit 4020b370f214315b8c10430301898ac21658143f

  28. Allow for plugin control over path generation strategies.

  29. Update some comments for fasthash

  30. Allow passing a pointer to GetNamedDSMSegment()'s init callback.

  31. Don't reset the pathlist of partitioned joinrels.

  32. Treat number of disabled nodes in a path as a separate cost metric.