| 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
| 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 |