Re: pg_plan_advice

On Tue, Feb 10, 2026 at 6:03 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I have committed those, as well as 0001 and 0002. Here's v15.

Here's v16. As a note, my biggest need right now is for some code
review. Testing help is, of course, also still very welcome.

What I have done in this version is run the test_plan_advice machinery
with the pg_plan_advice.feedback_warnings=on and try to fix as many of
the resulting failures as I could. The biggest revelation that I had
as a result of doing that is that it's really unfortunate for this
patch that get_relation_info_hook is only called for RTE_RELATION
baserels. I was somewhat aware of this problem before, but I thought
that it might be a non-critical thing that could be fixed at some
indefinite future point, maybe years in the future. However, this
testing convinced me that this could not really be postponed if I
wanted the patch set to actually work as intended. It's true that
there's nothing to control in terms of scan method for something like
a subquery scan, but you can want to control the placement of or
prevent the occurrence of Gather or Gather Merge nodes in join
problems that involve non-relation RTEs, and there's really no way to
do that with the existing hook placement.

But it seems like there's a pretty easy solution, which is to move the
hook up from get_relation_info to its sole caller, build_simple_rel.
Patch 0002 implements this and has a commit message explaining how
code that currently uses get_relation_info_hook can be modified to
work with the replacement, buld_simple_rel_hook.

The rest of the patch set is as before, except for the main patch, now
0003, which has the following additional changes:

- It has been updated to use build_simple_rel_hook rather than
get_relation_info_hook.

- I have corrected some order of operations problems in
pgpa_walk_recursively(). The previous coding code deliver incorrect
results when an elided SubqueryScan should have been considered the
only RTI-bearing plan node beneath a Gather or Gather Merge.

- I have adjusted pgpa_planner_apply_joinrel_advice() to fix a problem
where GATHER() or GATHER_MERGE() advice could be falsely reported as
conflicting with PARTITIONWISE() advice.

- I have adjusted pgpa_plan_walker() and pgpa_walk_recursively() to
fix a problem with Gather or Gather Merge nodes together with
partitionwise aggregation, where the generated plan advice was
sometimes incorrect.

- I have done some further work on the documentation. Specifically, I
added a list of known limitations, or at least the start of one; I
expanded the discussion of what "matched" and "partially matched"
mean; I expanded the discussion of how NO_GATHER works; and I and
changed some references from "table" to "relation".

- Comment improvements.

As you might or might not guess, a lot of these bug fixes and
documentation updates were indirect consequences of the replacement of
get_relation_info_hook with buld_simple_rel_hook. Once I made that
change, it fixed some problems, but revealed others which I then had
to fix or document. However, some of these fixes are just cleaning up
other things revealed by running test_plan_advice with
pg_plan_advice.feedback_warnings=on.

Even though I have been running test_plan_advice locally with
pg_plan_advice.feedback_warnings=on, I have not enabled that in this
version of the patch set. That's because that still causes 1 test
failure, due to self-join elimination doing something that perhaps it
shouldn't. More about that later, after I've further analyzed it.

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