Re: ReadRecentBuffer() doesn't scale well

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers(at)postgresql(dot)org, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: ReadRecentBuffer() doesn't scale well
Date: 2023-06-30 03:09:00
Message-ID: 20230630030900.pc6z2nidl4klqfhh@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-06-30 04:08:28 Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes
Previous Message Richard Guo 2023-06-30 03:05:36 Re: Assert !bms_overlap(joinrel->relids, required_outer)