Re: pg_plan_advice

On Thu, Feb 26, 2026 at 8:55 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Thanks, Alex, for the review.

Here's v18. In addition to fixing the problems pointed out by Alex,
there are a couple of significant changes in this version.

First, I realized that it might be confusing to have the collector
interface as part of pg_plan_advice, because for most of what
pg_plan_advice does, you didn't need the extension, but for that part,
you did. So, I broke that part out into its own extension, now called
pg_collect_advice, and put it into a separate patch. I think this is
conceptually cleaner: pg_plan_advice is just the core functionality of
generating and enforcing advice, and anything else is a separate
extension that logically sits on top of that core functionality. This
also has the advantage that you can decide to make the core
functionality available without any chance of somebody getting access
to the collector, if desired.

Second, I also added a third contrib module called pg_stash_advice.
This uses the same hook that I previously added for test_plan_advice,
but unlike that module, this one's not just a test. It lets you set up
an "advice stash" which is basically a query_id->advice_string hash
table. If you then set pg_stash_advice.stash_name to the name of your
advice stash, it will do a lookup into that hash table every time a
query is planned and, if the query ID is found, it will do the
planning with the corresponding advice string. What I think is
particularly cool about this is that it shows that you can really use
that hook to apply advice on the fly in any way you want. I suspect
that query ID matching will be suitable for a lot of use cases, but
you could have a similar module that matches on query text or does
anything else that you want as long as an advice string pops out at
the end. It shows that the core pg_plan_advice infrastructure is
pluggable. So this is both something that I think a lot of people will
find useful all on its own, and also a design pattern that people can
copy and adapt.

Finally, I did a lot of minor cleanups. I originally planned to try to
include a full list in this email, but as the number of fixes got
larger, I eventually realized that would get incredibly tedious, even
for me. An awful lot of what got fixed was just straightforward typos,
but there were also some comments where the wording was garbled and
didn't really make sense, or where I thought the comment should be
longer or shorter than it actually was, or where I used the wrong data
type in the code but in a way that didn't actually break anything.
There are a few fixes to the code, but they're all very minor stuff
that I'm not sure has any real-world consequences, although it might
so it's good to fix it, but the overwhelming bulk of it is cosmetic.

Thanks,

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