Re: wrong Append/MergeAppend elision?

On Fri, Jan 27, 2023 at 5:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > 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.
>
> > 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.
>
> Yeah. Amit's proposal amounts to optimizing for the case that all
> partitions get pruned, which does not seem to me to be the way
> to bet. I'm inclined to think it's fine as-is.

Fair enough. I thought for a second that maybe it was simply an
oversight but David confirms otherwise. This was interacting badly
with the other patch I'm working on and I just figured out the problem
was with that other patch.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com