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 | Resend email |
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
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 |