On Fri, 27 Jan 2023 at 01:30, Amit Langote <amitlangot...@gmail.com> wrote: > It seems that the planner currently elides an Append/MergeAppend that > has run-time pruning info (part_prune_index) set, but which I think is > a bug.
This is actually how I intended it to work. Whether it was a good idea or not, I'm currently unsure. I mentioned it in [1]. I think the plan shapes I was talking about were some ordered paths from partial paths per what is being added right at the end of add_paths_to_append_rel(). However, now that I look at it again, I'm not sure why it wouldn't be correct to still have those paths with a single-child Append. Certainly, the "if (list_length(live_childrels) == 1)" test made in add_paths_to_append_rel() is no longer aligned to the equivalent test in set_append_references(), so it's possible even now that we make a plan that uses the extra sorted partial paths added in add_paths_to_append_rel() and still have the Append in the final plan. There is still the trade-off of having to pull tuples through the Append node for when run-time pruning is unable to prune the last partition. So your proposal to leave the Append alone when there's run-time pruning info is certainly not a no-brainer. [1] https://www.postgresql.org/message-id/cakjs1f_utf1mbp8ueobyaarzio4e4qb4z8fksurpam+3q_h...@mail.gmail.com
