Feedback-ID: ia2694551:Fastmail
Date: Thu, 9 Nov 2023 12:25:13 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Ants Aasma <ants@cybertec.at>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
	Dilip Kumar <dilipbalaut@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning
 the SLRU lock
Message-ID: <202311091125.uqjmb757b4kb@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CANwKhkOwH5OPvP0ihhJLobqe17xmxfCLrsivqfcVrA6nfO4CcA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202311091125.uqjmb757b4kb%40alvherre.pgsql>
Precedence: bulk

IMO the whole area of SLRU buffering is in horrible shape and many users
are struggling with overall PG performance because of it.  An
improvement doesn't have to be perfect -- it just has to be much better
than the current situation, which should be easy enough.  We can
continue to improve later, using more scalable algorithms or ones that
allow us to raise the limits higher.

The only point on which we do not have full consensus yet is the need to
have one GUC per SLRU, and a lot of effort seems focused on trying to
fix the problem without adding so many GUCs (for example, using shared
buffers instead, or use a single "scaling" GUC).  I think that hinders
progress.  Let's just add multiple GUCs, and users can leave most of
them alone and only adjust the one with which they have a performance
problems; it's not going to be the same one for everybody.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)