On Wed, Aug 21, 2024 at 10:29:23AM -0400, Robert Haas wrote: > I went ahead and committed these patches. I know there's some debate > over whether we want to show the # of disabled nodes and if so whether > it should be controlled by COSTS, and I suspect I haven't completely > allayed David's concerns about the initial_cost_XXX functions although > I think that I did the right thing. But, I don't have the impression > that anyone is desperately opposed to the basic concept, so I think it > makes sense to put these into the tree and see what happens. We have > quite a bit of time left in this release cycle to uncover bugs, hear > from users or other developers, etc. about what problems there may be > with this. If we end up deciding to reverse course or need to fix a > bunch of stuff, so be it, but let's see what the feedback is.
I have been reviewing a bit what was done in the scope of this thread for some planner hint things, as in e22253467942 and 161320b4b960, and I just wanted to say thanks for committing these changes. In pg_hint_plan, we've been discussing lately some limitations with always appending disable_cost to all the nodes that we want disabled, up to v17. There were two proposals that turned around copying from the backend planner more cost-related logic to get a tighter control over the ordering of the node paths that we want disabled (pg_hint_plan needs may attempt to force a strict ordering, like for joins with Leading nodes), still relying on disable_cost brings a lot of limitations. The talks happened around these two issues, FYI: https://github.com/ossc-db/pg_hint_plan/pull/207 https://github.com/ossc-db/pg_hint_plan/pull/208 Let's just say that the proposals turned around copying more cost routines from the planner back into the module, which was a bad idea on maintenance ground. With v18, we do not need to do any of that anymore, as disabled_nodes takes priority over the costs. Not to mention that it's more helpful to know if the planner disabled a node without having to look at a cost close to an infinite value. A bunch of plans in the regression tests have changed while making the code stable with v18 because we show some nodes as disabled but still used by the planner, but that was not a big deal at the end. In short, thanks all for the work done here! -- Michael
signature.asc
Description: PGP signature