On Tue, May 1, 2018 at 11:58 AM, Robert Haas <robertmh...@gmail.com> wrote: >> All of that having been said, maybe we have an independent low-level >> problem: we increase usage_count when we pin a buffer, even if we last >> pinned the buffer 5ms ago. IIRC a change to this went in when ARC went >> in (and came out with ARC, too). This is more of a problem with >> miscounting the number of hits based on accidents around how things >> are structured in the executor -- we need to be more careful about >> recognizing whether or not block hits are logically distinct. >> Particularly with stuff like nested loop joins. > > I agree that double-counting correlated accesses is a a problem, and I > agree that we probably want to do something about it. I am skeptical > that using wall-clock time is the right way to solve that problem > because it leads to edge effects -- if for example there is a 5ms > timeout for bumping the usage count again, then you can probably > manufacture a workload where the buffer eviction pattern is > dramatically different for a nested loop that hits a given page every > 4.5ms than it is for a nested loop that hits a given page every 5.5ms. > Note that CART aims to solve this problem in a way that doesn't > involve any fixed amount of wall-clock time.
index_fetch_heap() calls ReleaseAndReadBuffer(), which will notice when the buffer it has been asked to read and pin is the same as the buffer it also needs to release/unpin. If they're the same buffer, which is probably very common, then it simply returns the existing buffer without releasing its pin. Naturally, pinning and unpinning increments the heap page's usage_count, which is really bad when references are correlated like this, so this is a really good idea. (Of course, we'd also like to avoid the actual work of pinning and unpinning, but that's arguably secondary -- this ReleaseAndReadBuffer() logic went in as part of the original 2005 clock sweep commit, so it seem to actually mostly be about correlated references.) I wonder if the significant improvements that I've noticed from the pending v3 of my nbtree-unique-key-heap-tid patch for certain workloads are related to ReleaseAndReadBuffer(), and if so to what degree. It's not hard to imagine how it could be a real problem that heap index tuple heap TIDs are in random order. ReleaseAndReadBuffer() could end up repeatedly pinning and unpinning the same heap pages when they appear again and again out of order on an nbtree leaf page. If that's true, then it might not matter how smart our algorithm is. -- Peter Geoghegan
