Re: EXPLAIN BUFFERS

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXPLAIN BUFFERS
Date: 2009-12-11 02:35:56
Message-ID: 20091211113555.8C70.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> >> I don't think IO is a terrible name for an option but I like BUFFERS
> >> better. ?I don't think the BUFFERS/BLOCKS confusion is too bad, but
> >> perhaps we could use BUFFERS in both places.
> >
> > I don't know how "blocks" got into here in the first place--this concept is
> > "buffers" just about everywhere else already, right?
>
> I think we have some places already in the system where we bounce back
> and forth between those terms. I expect that's the reason.

The "blocks" comes from pg_statio_all_tables.heap_blks_{read|hit},
but "buffers" might be easy to understand. One matter for concern
is that "buffer read" might not be clear whether it is a memory access
or a disk read.

Anyway, a revised patch according to the comments is attached.
The new text format is:
Buffers: shared hit=675 read=968, temp read=1443 written=1443
* Zero values are omitted. (Non-text formats could have zero values.)
* Rename "Blocks:" to "Buffers:".
* Remove parentheses and add a comma between shared, local and temp.

=# EXPLAIN (BUFFERS, ANALYZE) SELECT *
FROM pgbench_accounts a, pgbench_branches b
WHERE a.bid = b.bid AND abalance >= 0 ORDER BY abalance;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=54151.83..54401.83 rows=100000 width=461) (actual time=92.551..109.646 rows=100000 loops=1)
Sort Key: a.abalance
Sort Method: external sort Disk: 11544kB
Buffers: shared hit=675 read=968, temp read=1443 written=1443
-> Nested Loop (cost=0.00..4141.01 rows=100000 width=461) (actual time=0.048..42.190 rows=100000 loops=1)
Join Filter: (a.bid = b.bid)
Buffers: shared hit=673 read=968
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=364) (actual time=0.003..0.004 rows=1 loops=1)
Buffers: shared hit=1
-> Seq Scan on pgbench_accounts a (cost=0.00..2890.00 rows=100000 width=97) (actual time=0.038..22.912 rows=100000 loops=1)
Filter: (a.abalance >= 0)
Buffers: shared hit=672 read=968
Total runtime: 116.058 ms
(13 rows)

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center

Attachment Content-Type Size
explain_buffers_20091211.patch application/octet-stream 21.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-12-11 02:47:18 Re: SE-PostgreSQL/Lite Review
Previous Message Bruce Momjian 2009-12-11 02:23:38 Re: thread safety on clients