Re: ReadRecentBuffer() doesn't scale well

On Fri, 30 Jun 2023 at 07:43, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> 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. Ants Aasma
> mentioned that he was working on a tiny SIMD-based LRU that could be
> useful for something like that, without being too slow. Just for
> fun/experimentation, here's a simple attempt to use a very stupid
> stand-in LRU to cache the most recent 8 lookups for each fork of each
> relation. Obviously that will miss every time for many workloads so
> it'd have to be pretty close to free and this code probably isn't good
> enough, but perhaps Ants knows how to sprinkle the right magic fairy
> dust on it. It should automatically discover things like root pages,
> the heap target block during repeat inserts etc, and visibility map
> pages would stick around, and perhaps a few more pages of btrees that
> have a very hot key range (but not pgbench).
>
> > 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.

I have changed the status of commitfest entry to "Waiting on Author"
as Andres's comments were not discussed further. Feel free to handle
the comments and change the status accordingly for the commitfest
entry.

Regards,
Vignesh