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
