On Fri, 28 Aug 2026 at 15:03, Richard Guo <guofenglinux@gmail.com> 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
