From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 14 release notes, first draft |
Date: | 2021-05-11 02:57:10 |
Message-ID: | CA+HiwqG7DrugnZuFwe8pnhQmQth-cDOVubXtxDnL_n1JyXmL1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 10, 2021 at 11:40 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> Same as the last couple years, I checked for missing items in the release
> notes, running something like this.
>
> git log --cherry-pick --oneline origin/REL_13_STABLE...origin/master
>
> Should any of these be included?
>
> 86dc90056d Rework planning and execution of UPDATE and DELETE.
> a1115fa078 Postpone some more stuff out of ExecInitModifyTable.
> c5b7ba4e67 Postpone some stuff out of ExecInitModifyTable.
I was just about to ask Bruce what he thinks about these.
To clarify, the first one is a big refactoring commit that allowed us
to get rid of inheritance_planner(), a fairly inefficient way of
planning updates/deletes on partitioned tables, especially when many
partitions remain after pruning (or when pruning cannot be used). One
may see the performance of update/deletes, especially on partitioned
tables, to be generally improved as a result of this commit, but maybe
not as significantly as to be mentioned in E.1.3.1.1. Partitioning or
even E.1.3.1.4. General Performance. However, one user-visible
feature that came out of this work is that updates/deletes can now use
run-time pruning whereas they couldn't before. Maybe that ought to be
mentioned. (This reminds me to send a patch to remove the note from
5.11.4. Partition Pruning that says that runtime pruning cannot be
used for update/delete).
The other two commits can lead to improved performance of
update/deletes when there are many unpruned partitions in the plan,
but runtime pruning (a new feature as mentioned above) leads to only
one or few partitions to actually be updated/deleted from. I admit
though that the cases for which performance has been improved still
under-perform the cases that already performed better starting in v12,
that is, the cases where the planner itself is able to trim down the
plan to contain one or few partitions, so maybe nothing very big to
see here just yet. You may want to take a look at the benchmark
results I had posted here:
https://www.postgresql.org/message-id/CA%2BHiwqEcawatEaUh1uTbZMEZTJeLzbroRTz9_X9Z5CFjTWJkhw%40mail.gmail.com
Thank you.
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Lepikhov | 2021-05-11 02:58:10 | Re: Asynchronous Append on postgres_fdw nodes. |
Previous Message | Bruce Momjian | 2021-05-11 02:49:08 | Re: PG 14 release notes, first draft |