Re: pg_plan_advice

On Thu, Jan 15, 2026 at 7:28 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
> The last one seems to pass all my tests (with already provided fixup
> from yesterday), but I'm absolutely not sure if that's the proper way to
> address that).

Thanks. I don't think that's the right fix but the analysis was very
helpful to me in understanding the problem. I think the issue is that
the previous code was confusing "need to generate an advice string"
with "need to walk the plan tree". The latter is a superset of the
former, because we also need to walk the plan tree to generate advice
feedback.

So here's v10. 0001-0004 are unchanged, with the exception that in
0003, I have adjusted accumulate_append_subpath() to incorporate the
absorbed AppendPath's child_append_relid_sets into the surviving
AppendPath's child_append_relid_sets, instead of only the absorbed
AppendPath's relids proper. I don't think this makes any practical
difference to pg_plan_advice, but I might be wrong, and the old way
seems like an obvious oversight. 0005 has a bunch of small fixes,
thanks to all the review comments:

- Fixed mis-spelled Reviewed-by header for Ajay Pal.
- Added Reviewed-by header for John Naylor.
- Added modified version of the test case proposed by Jacob.
- Changed a "break" to "continue" in pgpa_occurrence_number. I don't
think this had any practical impact but it was inconsistent and
contradicted the comment.
- Added a new walk_plan_tree flag to pgpa_planner_state to avoid
getting confused about whether to build pgpa_sj_unique_rel objects.
- Don't let implicit join order constraints arising from join methord
or semijoin uniqueness advice to add to jo_permit_indexes.
- Don't consider join order advice fully matched if we only fully
matched a sublist.
- Remove pgpa_walker_get_rti and properly handle 0 return values from
pgpa_compute_rti_from_identifier instead.

I'm very appreciative to everyone for all the testing and reports
about 0005; I still do need some substantive code review particularly
of 0001.

Thanks,

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