Re: PG 14 release notes, first draft

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

In response to

Browse pgsql-hackers by date

  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