Feedback-ID: id4a34324:Fastmail
Date: Sun, 29 May 2022 13:57:07 -0700
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: SLRUs in the main buffer pool, redux
Message-ID: <20220529205707.jfmnp4fgjtpx32bw@alap3.anarazel.de>
References: 
 <CA+hUKGKAYze99B-jk9NoMp-2BDqAgiRC4oJv+bFxghNgdieq8Q@mail.gmail.com>
 <5ced6199-9fa2-722c-2163-4418ca907a95@iki.fi>
 <CA+hUKG+qzHB-mY3kym7JCQ-SbiO88hhiWKkUCfLMQmm7CbaCBw@mail.gmail.com>
 <CA+hUKGKCkbtOutcz5M8Z=0pgAkwdiR57Lxk7803rGsgiBNST6w@mail.gmail.com>
 <CA+hUKGKsqhCta2rWMJyJh75WHzNkMPvsN6zvDxaCsqp-gPUxOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGKsqhCta2rWMJyJh75WHzNkMPvsN6zvDxaCsqp-gPUxOw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220529205707.jfmnp4fgjtpx32bw%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2022-05-28 13:13:20 +1200, Thomas Munro wrote:
> 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.

Included in that is not needing to re-check that the identity of the buffer
changed since the last use and to not need a PrivateRefCountEntry. Neither is
cheap...

I'd structure it so that there's a small list of slru buffers that's pinned in
a "shared" mode. Entering the buffer into that increases the BufferDesc's
refcount, but is *not* memorialized in the backend's refcount structures,
because it's "owned by the SLRU".


> 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 very doubtful it's a good idea to combine those things - I think it's
quite different to come up with a design for SLRUs, of which there's a
constant number and shared memory ownership datastructures, and btree root
pages etc, of which there are arbitrary many.

For the nbtree (and similar) cases, I think it'd make sense to give backends a
size-limited number of pages they can keep pinned, but in a backend local
way. With, as you suggest, a procsignal barrier or such to force release.


> 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...

-many

That seems fragile and complicated, without, at least to me, a clear need.

Greetings,

Andres Freund