Re: ReadRecentBuffer() doesn't scale well

On Tue, Jun 27, 2023 at 4:53 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, Jun 26, 2023 at 9:40 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > If the goal is to get rid of both pins and content locks, LSN isn't
> > enough. A page might be evicted and replaced by another page that has
> > the same LSN because they were modified by the same record. Maybe
> > that's vanishingly rare, but the correct thing would be counter that
> > goes up on modification AND eviction.
>
> It should be safe to allow searchers to see a version of the root page
> that is out of date. The Lehman & Yao design is very permissive about
> these things. There aren't any special cases where the general rules
> are weakened in some way that might complicate this approach.
> Searchers need to check the high key to determine if they need to move
> right -- same as always.

OK. I guess I'm talking about a slightly more general version of the
problem inspired by the stuff I mentioned in parentheses, which would
simply get the wrong answer if the mapping changed, whereas here you'd
use the cached copy in a race case which should still work for
searches.

So I guess the question for this thread is: do we want to work on
ReadRecentBuffer(), or just take this experiment as evidence of even
more speed-up available and aim for that directly?