Horton

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

x4mmm@yandex-team.ru

View thread View on postgr.es
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, tender wang <tndrwang@gmail.com>, pgsql-hackers mailing list <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-26T18:21:18Z
Lists: pgsql-hackers 

> On 26 Jan 2024, at 22:38, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> This is OK because in the
> default compilation each file only has 32 segments, so that requires
> only 32 lwlocks held at once while the file is being deleted.

Do we account somehow that different subsystems do not accumulate MAX_SIMUL_LWLOCKS together?
E.g. GiST during split can combine 75 locks, and somehow commit_ts will be deactivated by this backend at the same moment and add 32 locks more :)
I understand that this sounds fantastic, these subsystems do not interfere. But this is fantastic only until something like that actually happens.
If possible, I'd prefer one lock at a time, any maybe sometimes two-three with some guarantees that this is safe.
So, from my POV first solution that you proposed seems much better to me.

Thanks for working on this!


Best regard, Andrey Borodin.

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.