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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: tender wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Date: 2024-01-31 23:31:34
Message-ID: 202401312331.dozxsouzpsvd@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2024-Jan-29, Dilip Kumar wrote:

> Thank you for working on this. There is one thing that I feel is
> problematic. We have kept the allowed values for these GUCs to be in
> multiple of SLRU_BANK_SIZE i.e. 16 and that's the reason the min
> values were changed to 16 but in this refactoring patch for some of
> the buffers you have changed that to 8 so I think that's not good.

Oh, absolutely, you're right. Restored the minimum to 16.

So, here's the patchset as two pieces. 0001 converts
SlruSharedData->latest_page_number to use atomics. I don't see any
reason to mix this in with the rest of the patch, and though it likely
won't have any performance advantage by itself (since the lock
acquisition is pretty much the same), it seems better to get it in ahead
of the rest -- I think that simplifies matters for the second patch,
which is large enough.

So, 0002 introduces the rest of the feature. I removed use of banklocks
in a different amount as banks, and I made commit_ts use a longer
lwlock acquisition at truncation time, rather than forcing all-lwlock

The more I look at 0002, the more I notice that some comments need badly
updated, so please don't read too much into it yet. But I wanted to
post it anyway for archives and cfbot purposes.

Álvaro Herrera PostgreSQL Developer —

Attachment Content-Type Size
0001-Use-atomics-for-SlruSharedData-latest_page_number.patch text/x-diff 7.5 KB
0002-Enlarge-SLRU-buffer-caches-and-improve-concurrency.patch text/x-diff 110.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2024-02-01 00:04:55 Re: speed up a logical replica setup
Previous Message Peter Smith 2024-01-31 22:48:05 Re: Documentation: warn about two_phase when altering a subscription