Re: ReadRecentBuffer() doesn't scale well - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ReadRecentBuffer() doesn't scale well
Date
Msg-id 20230630030900.pc6z2nidl4klqfhh@awork3.anarazel.de
Whole thread Raw
In response to Re: ReadRecentBuffer() doesn't scale well  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hi,

On 2023-06-30 14:13:11 +1200, Thomas Munro wrote:
> On Fri, Jun 30, 2023 at 3:39 AM Andres Freund <andres@anarazel.de> wrote:
> > I am wondering if we don't want something more generic than stashing this in
> > rd_amcache. Don't want to end up duplicating relevant code across the uses of
> > rd_amcache in every AM.
> 
> I suppose we could try to track hot pages automatically.

I think that could be useful - but as a separate facility. The benefit of
stashing the root page buffer in the relcache is that it's practically free of
overhead and doesn't have complications from how many other intervening
accesses there are etc.

I was more thinking of just making the relevant fields part of RelationData
and delegating the precise use to the individual AMs.


> > I do wonder if we should have an unlocked pre-check for a) the buffer being
> > valid and b) BufferTagsEqual() matching.  With such a pre-check the race for
> > increasing the usage count of the wrong buffer is quite small, without the
> > pre-check it doesn't seem that small anymore.
> 
> Yeah, that makes sense.  Done in this version.

Cool.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Assert !bms_overlap(joinrel->relids, required_outer)
Next
From: Amit Kapila
Date:
Subject: Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes