Feedback-ID: ia2694551:Fastmail
Date: Fri, 23 Feb 2024 12:48:11 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, tender wang <tndrwang@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning
 the SLRU lock
Message-ID: <202402231148.lqruleoappvd@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EF717C6D-0535-4DF2-BD54-9B792FAB0B07@yandex-team.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/202402231148.lqruleoappvd%40alvherre.pgsql>
Precedence: bulk

On 2024-Feb-23, Andrey M. Borodin wrote:

> I'm sure anyone with multiple CPUs should increase, not decrease
> previous default of 128 buffers (with 512MB shared buffers). Having
> more CPUs (the only way to benefit from more locks) implies bigger
> transaction buffers.

Sure.

> IMO making bank size variable adds unneeded computation overhead, bank
> search loops should be unrollable by compiler etc.

Makes sense.

> Originally there was a patch set step, that packed bank's page
> addresses together in one array. It was done to make bank search a
> SIMD instruction.

Ants Aasma had proposed a rework of the LRU code for better performance.
He told me it depended on bank size being 16, so you're right that it's
probably not a good idea to make it variable.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/