Re: wrong Append/MergeAppend elision? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: wrong Append/MergeAppend elision?
Date
Msg-id 3169202.1674765805@sss.pgh.pa.us
Whole thread Raw
In response to Re: wrong Append/MergeAppend elision?  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: wrong Append/MergeAppend elision?
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Fri, 27 Jan 2023 at 01:30, Amit Langote <amitlangote09@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.

> 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: lockup in parallel hash join on dikkop (freebsd 14.0-current)
Next
From: Andres Freund
Date:
Subject: Re: New strategies for freezing, advancing relfrozenxid early