On Fri, Aug 28, 2026 at 10:21:29AM -0400, Robert Haas wrote: > On Thu, Aug 27, 2026 at 1:18 PM Noah Misch <[email protected]> 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.
