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

On Tue, Feb 27, 2024 at 11:41 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> On 2024-Feb-27, Alvaro Herrera wrote:
>
> > Here's the complete set, with these two names using the singular.
>
> BTW one thing I had not noticed is that before this patch we have
> minimum shmem size that's lower than the lowest you can go with the new
> code.
>
> This means Postgres may no longer start when extremely tight memory
> restrictions (and of course use more memory even when idle or with small
> databases). I wonder to what extent should we make an effort to relax
> that. For small, largely inactive servers, this is just memory we use
> for no good reason. However, anything we do here will impact
> performance on the high end, because as Andrey says this will add
> calculations and jumps where there are none today.
>
>
I was just comparing the minimum memory required for SLRU when the system
is minimally configured, correct me if I am wrong.

SLRU unpatched
patched
commit_timestamp_buffers 4 16
subtransaction_buffers 32 16
transaction_buffers 4 16
multixact_offset_buffers 8 16
multixact_member_buffers 16 16
notify_buffers 8
16
serializable_buffers 16 16
-------------------------------------------------------------------------------------
total buffers 88
112

so that is < 200kB of extra memory on a minimally configured system, IMHO
this should not matter.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com