On Fri, 28 Aug 2026 at 15:03, Richard Guo <[email protected]> wrote: > Maybe 47c110f77 and 6e466e1e8 should have been back-patched too?
On a quick glance, what I said seems to apply to both of those commits too, but I'm no authority on the matter. I'm just telling you what I think. My understanding of "don't backpatch as that might cause plan changes" is so we don't accidentally cause an inadvertent plan change for someone who has already tested their workload on that major version of PostgreSQL and is happy enough with the performance. If someone has disabled a node and we don't obey that disabled property, then that seems like a bug fix for a feature that's not working as intended. If they disabled the node type, then they quite clearly want to avoid using that node type either completely or whenever there's no other alternative plan. I also think the one reported here is slightly worse due to the behaviour depending on the number of pruned partitions. I didn't study it in detail, but it looks to me like 47c110f77 and 6e466e1e8 are more likely to consistently do the wrong thing, but you might tell me I'm wrong there as it looks like you've looked at those issues in more detail than I have. David
