At Thu, 12 Jul 2018 10:31:46 +1200, Thomas Munro <thomas.munro@enterprisedb.com> wrote in
<CAEepm=2yGnw6dJ5wx8tuSRmcpDZ5uziiH_qQ0ptdha8mMLSVqw@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.haribabu@gmail.com> wrote in
<CAJrrPGduEpxwtu9VFxT21DNK=WRP=LUjK4GjPfm+4+PCjpcAxA@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.rowley@2ndquadrant.com> wrote in
<CAKJS1f_kem=OzVpFADzC2=VpzcXuSQ+HCW=Hp67GAXrnQ-EVTw@mail.gmail.com>
> On 12 July 2018 at 12:19, Haribabu Kommi <kommi.haribabu@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