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

From Thomas Munro
Subject Re: SLRUs in the main buffer pool, redux
Date
Msg-id CA+hUKGKsqhCta2rWMJyJh75WHzNkMPvsN6zvDxaCsqp-gPUxOw@mail.gmail.com
Whole thread Raw
In response to Re: SLRUs in the main buffer pool, redux  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: SLRUs in the main buffer pool, redux
Re: SLRUs in the main buffer pool, redux
List pgsql-hackers
On Fri, May 27, 2022 at 11:24 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Rebased, debugged and fleshed out a tiny bit more, but still with
> plenty of TODO notes and questions.  I will talk about this idea at
> PGCon, so I figured it'd help to have a patch that actually applies,
> even if it doesn't work quite right yet.  It's quite a large patch but
> that's partly because it removes a lot of lines...

FWIW, here are my PGCon slides about this:
https://speakerdeck.com/macdice/improving-the-slru-subsystem

There was a little bit of discussion on #pgcon-stream2 which I could
summarise as: can we figure out a way to keep parts of the CLOG pinned
so that backends don't have to do that for each lookup?  Then CLOG
checks become simple reads.  There may be some relation to the idea of
'nailing' btree root pages that I've heard of from a couple of people
now (with ProcSignalBarrier or something more fine grained along those
lines if you need to unnail anything).  Something to think about.

I'm also wondering if it would be possible to do "optimistic" pinning
instead for reads that normally need only a pin, using some kind of
counter scheme with read barriers to tell you if the page might have
been evicted after you read the data...



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Next
From: Michael Paquier
Date:
Subject: Re: Assert name/short_desc to prevent SHOW ALL segfault