From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 14 release notes, first draft |
Date: | 2021-05-12 06:59:09 |
Message-ID: | CA+HiwqGWr9Ax=5bfKyN5TZ_7=Dupf5WtXm4xPzdL+a4Ed8z3Eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 12, 2021 at 6:47 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2021-May-11, Bruce Momjian wrote:
>
> > > 86dc90056d Rework planning and execution of UPDATE and DELETE.
> > > a1115fa078 Postpone some more stuff out of ExecInitModifyTable.
> > > c5b7ba4e67 Postpone some stuff out of ExecInitModifyTable.
>
> Are these the set that means UPDATE/DELETE can now do partition pruning?
> I think that's a significant improvement, because table partitioning
> becomes usable in situations where it previously wasn't, so let's
> mention it.
Thanks. To be clear, update/delete can now do *run-time* partition
pruning, while plan-time pruning has already been working since v12
(commit 428b260f87). How? The plan for update/delete now looks very
similar to that for an equivalent select query -- Append/MergeAppend
to scan partitions, with ModifyTable on top to do the actual
update/delete -- and because Append/MergeAppend nodes carry run-time
pruning info, update/delete now get that ability.
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-05-12 07:01:43 | Re: Parallel INSERT SELECT take 2 |
Previous Message | Pavel Stehule | 2021-05-12 06:58:45 | Re: compute_query_id and pg_stat_statements |