Explain buffers display units. - Mailing list pgsql-hackers

From Greg Stark
Subject Explain buffers display units.
Date
Msg-id 407d949e1002141725r7d9adb62h520df1f2b352369a@mail.gmail.com
Whole thread Raw
Responses Re: Explain buffers display units.  (Greg Smith <greg@2ndquadrant.com>)
Re: Explain buffers display units.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
So this is what I did about my two complaints earlier about the
explain buffer patch.

a) Changed the line description to "Total Buffer Usage" which at least
hints that it's something more akin to the "Total runtime" listed at
the bottom than the "actual time".

b) Used units of memory -- I formatted them with 3 significant digits
(unless the unit is bytes or kB where that would be silly). It's just
what looked best to my eye.

I'm finding "hit" and "read" kind of confusing myself but don't really
have any better idea. It's not entirely clear whether read is the
total accesses out of which some are cache hits or if they're two
disjoint sets.

postgres=# explain (analyze,buffers) select * from x limit 10000;
                                                   QUERY PLAN
-----------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..266.68 rows=10000 width=105) (actual
time=0.023..53.964 rows=10000 loops=1)
   Total Buffer Usage: shared hit=8kB read=1.30MB
   ->  Seq Scan on x  (cost=0.00..10667.00 rows=400000 width=105)
(actual time=0.019..20.311 rows=10000 loops=1)
         Total Buffer Usage: shared hit=8kB read=1.30MB
 Total runtime: 71.074 ms
(5 rows)

--
greg

Attachment

pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync
Next
From: Tom Lane
Date:
Subject: LISTEN/NOTIFY and notification timing guarantees