Re: SLRUs in the main buffer pool, redux - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: SLRUs in the main buffer pool, redux
Date
Msg-id 5ced6199-9fa2-722c-2163-4418ca907a95@iki.fi
Whole thread Raw
In response to SLRUs in the main buffer pool, redux  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: SLRUs in the main buffer pool, redux
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: New developer papercut - Makefile references INSTALL
Next
From: Magnus Hagander
Date:
Subject: Re: New developer papercut - Makefile references INSTALL