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

From: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
To: Ants Aasma <ants(at)cybertec(dot)at>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Date: 2023-11-08 09:32:48
Message-ID: 2DAF3D59-68C6-4659-A282-C03B44C1AF4A@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 8 Nov 2023, at 14:17, Ants Aasma <ants(at)cybertec(dot)at> wrote:
>
> Is there a particular reason why lock partitions need to be bigger? We have one lock per buffer anyway, bankwise locks will increase the number of locks < 10%.

The problem was not attracting much attention for some years. So my reasoning was that solution should not have any costs at all. Initial patchset with banks did not add any memory footprint.

> On 8 Nov 2023, at 14:17, Ants Aasma <ants(at)cybertec(dot)at> wrote:
>
> I am working on trying out a SIMD based LRU mechanism that uses a 16 entry bank.

FWIW I tried to pack struct parts together to minimize cache lines touched, see step 3 in [0]. So far I could not prove any performance benefits of this approach. But maybe your implementation will be more efficient.

Thanks!

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/93236D36-B91C-4DFA-AF03-99C083840378@yandex-team.ru

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-11-08 09:49:03 Re: Synchronizing slots from primary to standby
Previous Message Ants Aasma 2023-11-08 09:17:23 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock