Re: pg_*_advice: tsv load failure, etc.

On Fri, Aug 28, 2026 at 10:21:29AM -0400, Robert Haas wrote:
> On Thu, Aug 27, 2026 at 1:18 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > ### 14. Stash-supplied advice silently overrides an explicitly-set pg_plan_advice.advice for the same query; the precedence is documented nowhere
> >
> > I do feel the GUC should preempt the stash. Best to solidify this behavior
> > before release.
>
> IMHO, it's impossible to look at
> pg_plan_advice_get_supplied_query_advice() and think that the current
> behavior was anything but intentional. Of course, that doesn't mean
> it's optimal, but if you'd like to propose changing it, I suggest
> starting a new thread on that specific topic and making some kind of
> argument for your preferred behavior. I suspect a lot of people are
> going to think that this thread is just about bug-fixing, rather than
> proposed behavior changes. I'm fine with changing this if others
> agree.

I agree the pg_plan_advice implementation gives what the code calls "advisors"
precedence over this GUC. I opined this way because, as a user, I expect
more-specific knobs to override less-specific knobs. The stash is the less
specific of the two. That said, I don't plan to pursue this precedence
question further.

> > Here's the second tier, as I see it:
> >
> > ### 5. pg_plan_advice.advice / stash advice changes are silently ignored by an already-cached generic plan
>
> This is a planner control feature; it does not affect behavior other
> than at plan time. I don't see that as a bug. That said, I think it
> would be perfectly valid for someone to try to figure a way for advice
> stash changes to invalidate plans, but I suspect that will require
> significant new infrastructure. Plan invalidation is generally tied to
> catalog modifications, and here we would instead want to tie it to a
> plan ID. We could do that by adding a custom invalidation type to
> sinval.h just for the use of pg_stash_advice, but would be a pretty
> serious piece of core infrastructure for an as-yet-unproven contrib
> module to use to solve a problem which (for all we know now) may have
> little practical impact.

True, best to leave that as-is.