| 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-27 11:35:58 |
| Message-ID: | CAApHDvr5wuruXxx5nfhXT0njC4Z1ve3dx2iUdVmBqVJMzjinmQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 27 Aug 2026 at 19:36, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> For the same reason as those commits, I'd also leave this master-only.
> It is a v17 regression, but planner fixes risk destabilizing plans in
> stable branches, and this doesn't seem severe enough to be an
> exception.
IMO, disabling a node type is quite a clear request that you only want
that node type used if there's no alternative. I don't think the
normal reasons for not wanting to destabilise plans here apply to
this. If you leave this in, it'll mean there could be an inability in
what happens based on how many partitions are pruned. It's also hard
to imagine someone complaining that we stopped picking the plan with
the disabled node type and started choosing the next best alternative.
If they don't like the fact that the bug got fixed because they want
the plan with the disabled node, then why do they have that node
disabled in the first place?
It just feels more likely someone will encounter undesired behaviour
as a result of this rather than accidentally getting something good
out of it.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2026-08-27 11:45:21 | Re: [PATCH] Add tests for src/backend/nodes/extensible.c |
| Previous Message | Andrey Borodin | 2026-08-27 11:17:31 | Re: [PATCH] Fix timeline history after recovery stops on an ancestor |