On Tue, Feb 4, 2020 at 2:23 AM Andres Freund <and...@anarazel.de> wrote: > On 2019-12-31 17:05:31 +1300, Thomas Munro wrote: > > There is one potentially interesting case that doesn't require any > > kind of shared cache invalidation AFAICS. XLogReadBufferExtended() > > calls smgrnblocks() for every buffer access, even if the buffer is > > already in our buffer pool. > > Yea, that's really quite bad*. The bit about doing so even when already > in the buffer pool is particularly absurd. Needing to have special > handling in mdcreate() for XLogReadBufferExtended() always calling it is > also fairly ugly.
Yeah. It seems like there are several things to fix there. So now I'm wondering if we should start out by trying to cache the size it in the smgr layer for recovery only, like in the attached, and then later try to extend the scheme to cover the shared case as discussed at the beginning of the thread. > A word of caution about strace's -c: In my experience the total time > measurements are very imprecise somehow. I think it might be that some > of the overhead of ptracing will be attributed to the syscalls or such, > which means frequent syscalls appear relatively more expensive than they > really are. Yeah, those times are large, meaningless tracing overheads. While some systems might in fact be happy replaying a couple of million lseeks per second, (1) I'm pretty sure some systems would not be happy about that (see claims in this thread) and (2) it means you can't practically use strace on recovery because it slows it down to a crawl, which is annoying.
0001-Use-cached-smgrnblocks-results-in-recovery.patch
Description: Binary data
