On Sat, Apr 4, 2026 at 5:02 PM Andrei Lepikhov <[email protected]> wrote: > That’s exactly what concerns me. I see it as a potential design flaw if > the extension has to make assumptions about possible plan configurations. > I’m not sure how it works in detail, of course. However, when I designed > Postgres replanning in the past, and made similar core changes to what > you’ve done for pg_plan_advice, this kind of problem couldn’t have > happened. So, I think it’s worth questioning the current approach and > looking for other options.
I mean, any plan stability feature is intrinsically tied to a particular planner. Nobody thinks you can use Aurora Postgres's Query Plan Management feature with MySQL or DB2 or Oracle. Those products obviously have to have their own features for plan stability. The same is true here. There's more overlap because you're creating the plan out of the same basic building blocks rather than an entirely different set of things, but if you assemble them in a way that PostgreSQL doesn't, then some things may not work. pg_plan_advice is one of those things; the executor is another. Of course, I don't think anybody here is keen to break stuff for no good reason, which is why I will take a look at the report you posted. But fundamentally, it's the same issue. If somebody uses a plugin that replaces large parts of the plan with a CustomScan, pg_plan_advice isn't going to work with that, either: how could it possibly? Maybe there could be some way to make pg_plan_advice pluggable so that if extensions fiddle with the planner they can also do matching fiddling with pg_plan_advice if they're so inclined, but having it "just work" would require magic. -- Robert Haas EDB: http://www.enterprisedb.com
