Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS)
Date
Msg-id CAEepm=3AWXmXg4ZM5iO3_=ZcGw7z-s=JeVpLKnk1svdqzA+bKw@mail.gmail.com
Whole thread Raw
In response to Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS)  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS)  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Mon, Nov 19, 2018 at 5:24 PM Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> At Sat, 17 Nov 2018 11:15:54 -0300, Alvaro Herrera <alvherre@2ndquadrant.com> wrote in
<20181117141554.4dkx2u4j6md3bqdh@alvherre.pgsql>
> > Is this patch committable now?
>
> I don't think so. We should make a decision on a point.
>
> I was a bit confused (sorry) but IIUIC Haribabu suggested that
> the RBM_ZERO_ON_ERROR case should be included to read (not just
> ignored). I'm on it.  I think that RPM_ZERO_* other than ON_ERROR
> cases could be a kind of hit but I don't insist on it.
>
> So, I think we should decide on at least the ON_ERROR case before
> this becomes commttable.

Agreed, RBM_ZERO_ON_ERROR needs to be counted as a read.  Here's a new
version like that.

> The another counter could be another issue. I don't object to add
> the counter but I'm not sure what is the suitable name.

I think that might be interesting information in the future, but let's
consider that for a later patch.

-- 
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process