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

From Amit Langote
Subject Re: wrong Append/MergeAppend elision?
Date
Msg-id CA+HiwqHw4bkBY=2SsAhL4rqC=OLQbNC6dTgCOhMKGSmX5BvuVw@mail.gmail.com
Whole thread Raw
In response to Re: wrong Append/MergeAppend elision?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 27, 2023 at 5:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Something is wrong with wal_compression