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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads
Date: 2017-10-31 09:30:11
Message-ID: CA+TgmobLpsPt4mZ9j2CR_GUdmbjWZA786sxZie6ntRo-Z9zv0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Tue, Oct 17, 2017 at 2:29 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-10-31 09:43:10 Re: Restricting maximum keep segments by repslots
Previous Message Simon Riggs 2017-10-31 09:25:04 Re: MERGE SQL Statement for PG11