On 13/01/2022 15:59, Thomas Munro wrote:
> Hi,
>
> I was re-reviewing the proposed batch of GUCs for controlling the SLRU
> cache sizes[1], and I couldn't resist sketching out $SUBJECT as an
> obvious alternative. This patch is highly experimental and full of
> unresolved bits and pieces (see below for some), but it passes basic
> tests and is enough to start trying the idea out and figuring out
> where the real problems lie. The hypothesis here is that CLOG,
> multixact, etc data should compete for space with relation data in one
> unified buffer pool so you don't have to tune them, and they can
> benefit from the better common implementation (mapping, locking,
> replacement, bgwriter, checksums, etc and eventually new things like
> AIO, TDE, ...).
+1
> I know that many people have talked about doing this and maybe they
> already have patches along these lines too; I'd love to know what
> others imagined differently/better.
IIRC one issue with this has been performance. When an SLRU is working
well, a cache hit in the SLRU is very cheap. Linearly scanning the SLRU
array is cheap, compared to computing the hash and looking up a buffer
in the buffer cache. Would be good to do some benchmarking of that.
I wanted to do this with the CSN (Commit Sequence Number) work a long
time ago. That would benefit from something like an SLRU with very fast
access, to look up CSNs. Even without CSNs, if the CLOG was very fast to
access we might not need hint bits anymore. I guess trying to make SLRUs
faster than they already are is moving the goalposts, but at a minimum
let's make sure they don't get any slower.
- Heikki
