Horton

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

x4mmm@yandex-team.ru

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

> On 7 Feb 2024, at 10:58, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> 
>> commit_timestamp_slru_buffers
>> transaction_slru_buffers
>> etc
> 
> I am not sure we are exposing anything related to SLRU to the user, 

I think we already tell something about SLRU to the user. I’d rather consider if “transaction_slru_buffers" is easier to understand than “transaction_buffers” ..
IMO transaction_buffers is clearer. But I do not have strong opinion.

> I
> mean transaction_buffers should make sense for the user that it stores
> transaction-related data in some buffers pool but whether that buffer
> pool is called SLRU or not doesn't matter much to the user IMHO.
+1


Best regards, 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.