Re: [PATCH] Fix disabled_nodes propagation for single-child Append paths

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tender Wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, zengman(at)halodbtech(dot)com
Subject: Re: [PATCH] Fix disabled_nodes propagation for single-child Append paths
Date: 2026-08-28 05:02:27
Message-ID: CAApHDvrbSRaxG7g=cwnk7opQyDM7kWYduo=v5k3M98HyQW_4gg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 28 Aug 2026 at 15:03, Richard Guo <guofenglinux(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Koshino Taiki 2026-08-28 05:09:38 Re: doc: Reformat SELECT queries using GRAPH_TABLE
Previous Message shveta malik 2026-08-28 04:54:32 Re: Publication of same parent table with ONLY-ness mismatch should error