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

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)