Re: [HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads

[Robert Haas]

On Tue, Oct 17, 2017 at 2:29 AM, Thomas Munro
 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

[HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads

[Thomas Munro]

Hi hackers,

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

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


0001-Don-t-count-EOF-as-a-temporary-buffer-read-in-EXPLAI.patch
Description: Binary data

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