At Thu, 12 Jul 2018 10:31:46 +1200, Thomas Munro <thomas.mu...@enterprisedb.com> wrote in <CAEepm=2ygnw6dj5wx8tusrmcpdz5uziih_qq0ptdha8mmls...@mail.gmail.com> > I suppose someone might argue that even when it's not a hit and it's > not a read, we might still want to count this buffer interaction in > some other way. Perhaps there should be a separate counter? It may > technically be a kind of cache miss, but it's nowhere near as > expensive as a synchronous system call like read() so I didn't propose > that.
At Thu, 12 Jul 2018 10:19:29 +1000, Haribabu Kommi <kommi.harib...@gmail.com> wrote in <CAJrrPGduEpxwtu9VFxT21DNK=WRP=lujk4gjpfm+4+pcjpc...@mail.gmail.com> > Thanks for the details. I got your point. But we need to include > RBM_ZERO_ON_ERROR case read operations, excluding others > are fine. FWIW I agree to Haribabu's comment that the case of RBM_ZERO_* other than ON_ERROR is a hit. It seems to show zheap's disk I /O reduction by itself in certain extent. At Thu, 12 Jul 2018 13:28:37 +1200, David Rowley <david.row...@2ndquadrant.com> wrote in <CAKJS1f_kem=OzVpFADzC2=VpzcXuSQ+HCW=hp67gaxrnq-e...@mail.gmail.com> > On 12 July 2018 at 12:19, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > Yes, I agree that we may need a new counter that counts the buffers that > > are just allocated (no read or no write). But currently, may be the counter > > value is very less, so people are not interested. > The existing counters don't show up in EXPLAIN (ANALYZE, BUFFERS) when > they're zero. The new counter would surely work the same way, so the > users wouldn't be burdened by additional explain output it when > they're not affected by it. I don't object strongly neither to the new counter but I'm not sure it is enough distinctive from hits, in the view that "a hit is where we found a buffer for the requested page". regards. -- Kyotaro Horiguchi NTT Open Source Software Center
