On Tue, Jun 27, 2023 at 4:53 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Mon, Jun 26, 2023 at 9:40 PM Thomas Munro <thomas.mu...@gmail.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?