Re: [HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporarybuffer reads - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporarybuffer reads
Date
Msg-id CA+TgmobLpsPt4mZ9j2CR_GUdmbjWZA786sxZie6ntRo-Z9zv0Q@mail.gmail.com
Whole thread Raw
In response to [HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Tue, Oct 17, 2017 at 2:29 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Vik Fearing asked off-list why hash joins appear to read slightly more
> temporary data than they write.  The reason is that we notch up a
> phantom block read when we hit the end of each file.  Harmless but it
> looks a bit weird and it's easily fixed.
>
> Unpatched, a 16 batch hash join reports that we read 30 more blocks
> than we wrote (2 per batch after the first, as expected):
>
>    Buffers: shared hit=434 read=16234, temp read=5532 written=5502
>
> With the attached patch:
>
>    Buffers: shared hit=547 read=16121, temp read=5502 written=5502

Committed.  Arguably we ought to back-patch this, but it's minor so I didn't.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots