Horton
Menu

Re: pg_plan_advice

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
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>
Date: 2026-01-28T17:13:39Z
Lists: pgsql-hackers

Attachments

On Mon, Jan 12, 2026 at 12:13 PM Robert Haas <robertmhaas@gmail.com> wrote:
> If not, I'll rearrange
> the series to move 0004 to the front, and plan to commit that first.

That rearrangement got done in v11, and I've now committed that patch
after fixing a few typos that I found. Cautiously, woohoo, but let's
see if anything breaks.

Here's v13. Aside from dropping the now-committed patch, the other big
change here is that I've fixed the way bitmap heap scans work by
reducing scope. Previously, you could write things like
BITMAP_HEAP_SCAN(foo some_foo_idx) or BITMAP_HEAP_SCAN(foo
&&(foo_a_idx foo_b_idx)) to try to compel a particular choice of index
with a bitmap heap scan; however, it didn't actually work. I've now
removed that, and now all of the arguments to BITMAP_HEAP_SCAN() are
relation identifiers, and it specifies only that they should use some
kind of bitmap heap scan. I'm not sure that this is the right thing to
do, but it might be, for a couple of reasons:

1. The decision as to what should be included in a bitmap path is not
made by the general costing machinery, but by choose_bitmap_and(),
which uses its own special algorithm. A general principle of
pg_plan_advice is that it doesn't let you force the optimizer to
consider options that are rejected for reasons other than cost. This
is a grey area. choose_bitmap_and() considers cost, but it also has
other heuristics to limit the search space. We could allow overriding
the former part of the heuristic but not the latter, but that seems
complicated, and might also make this whole thing even more confusing
to use, since it would be really unclear why you could force some
index combinations and not others. We could also allow forcing any
combination, but that needs a lot of thought, since it deviates from
the general design principle and might open a king-sized can of worms.
Point being, the idea that BITMAP_HEAP_SCAN() has no business allowing
an index specification in the first place is not completely without
merit.

2. The only situations in which we consider multiple actual bitmap
paths (vs. potential bitmap paths, as discussed in the previous point)
is when there are possibly-useful parameterizations that we don't want
to ignore. However, I studied what happens in the core regression
tests, and it seems like we don't really have that many test cases
where just forcing some kind of bitmap heap scan wouldn't be good
enough. To use a parameterized bitmap heap scan path, we have to be
under the inner side of a nested loop with the parameterized rel on
the other side, so if the advice produces any other join order or join
method, then the parameterized paths won't even be considered and
there's only one path to choose from. However, it is true that we
might make the wrong decision about which bitmap path to use on the
inner side of a parameterized nested loop. In the future, that could
be addressed either by adding control over choice of parameterization
or by re-adding something like what I had in earlier patch versions
where you can specify particular indexes. But. I don't think we need
to decide right now which of those things we might ultimately want to
do.

(Another interesting point is that in a healthy number of cases where
we consider both parameterized and unparameterized bitmap paths, we
consider the same indexes or sets of indexes in both cases.)

I've gone ahead and removed the "WIP" designation from the
pg_plan_advice patch in this version. There are still a few areas that
need some more investigation, and I'm sure there are still bugs, but I
feel like the bitmap scan thing was the last really big area where
there was a huge problem staring any potential reviewer right in the
face. The remaining XXX comments are things where review comments
would actually be pretty helpful -- not to tell me that I have an XXX
comment, but to suggest what the resolution might be. Of course, I'll
continue looking into that on my own, as well.

Thanks to all who have reviewed so far, and please keep it coming. I
am especially in need of more code review at this point.

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

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.