| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: wrong Append/MergeAppend elision? |
| Date: | 2023-01-26 20:43:25 |
| Message-ID: | 3169202.1674765805@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-01-26 20:45:14 | Re: New strategies for freezing, advancing relfrozenxid early |
| Previous Message | Tomas Vondra | 2023-01-26 20:36:06 | lockup in parallel hash join on dikkop (freebsd 14.0-current) |