Horton

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, tender wang <tndrwang@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-23T11:48:11Z
Lists: pgsql-hackers 
On 2024-Feb-23, Andrey M. Borodin wrote:

> I'm sure anyone with multiple CPUs should increase, not decrease
> previous default of 128 buffers (with 512MB shared buffers). Having
> more CPUs (the only way to benefit from more locks) implies bigger
> transaction buffers.

Sure.

> IMO making bank size variable adds unneeded computation overhead, bank
> search loops should be unrollable by compiler etc.

Makes sense.

> Originally there was a patch set step, that packed bank's page
> addresses together in one array. It was done to make bank search a
> SIMD instruction.

Ants Aasma had proposed a rework of the LRU code for better performance.
He told me it depended on bank size being 16, so you're right that it's
probably not a good idea to make it variable.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Commits

  1. Fix zeroing of pg_serial page without SLRU bank lock

  2. Fix misspelled assertions

  3. GUC table: Add description to computed variables

  4. Improve performance of subsystems on top of SLRU

  5. Rename SLRU elements in view pg_stat_slru

  6. Use atomic access for SlruShared->latest_page_number

  7. Split use of SerialSLRULock, creating SerialControlLock

  8. Index SLRUs by 64-bit integers rather than by 32-bit integers

  9. Add a macro templatized hashtable.