pgsql: bufmgr: Acquire and clean victim buffer separately

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: bufmgr: Acquire and clean victim buffer separately
Date: 2023-04-05 20:49:24
Message-ID: E1pkA4J-001Y30-25@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

bufmgr: Acquire and clean victim buffer separately

Previously we held buffer locks for two buffer mapping partitions at the same
time to change the identity of buffers. Particularly for extending relations
needing to hold the extension lock while acquiring a victim buffer is
painful.But it also creates a bottleneck for workloads that just involve
reads.

Now we instead first acquire a victim buffer and write it out, if
necessary. Then we remove that buffer from the old partition with just the old
partition's partition lock held and insert it into the new partition with just
that partition's lock held.

By separating out the victim buffer acquisition, future commits will be able
to change relation extensions to scale better.

On my workstation, a micro-benchmark exercising buffered reads strenuously and
under a lot of concurrency, sees a >2x improvement.

Reviewed-by: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Reviewed-by: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/dad50f677c42de207168a3f08982ba23c9fc6720

Modified Files
--------------
src/backend/storage/buffer/bufmgr.c | 558 +++++++++++++++++++---------------
src/backend/storage/buffer/localbuf.c | 115 +++----
2 files changed, 369 insertions(+), 304 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2023-04-05 20:59:25 pgsql: Support "Right Anti Join" plan shapes.
Previous Message Tom Lane 2023-04-05 19:56:41 pgsql: Acquire locks on views in AcquirePlannerLocks, too.