Re: wrong Append/MergeAppend elision?

On Fri, 27 Jan 2023 at 01:30, Amit Langote <amitlangote09(at)gmail(dot)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_HOmQ@mail.gmail.com