Re: EXPLAIN BUFFERS

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

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Takahiro Itagaki escribi:
>> Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0) (temp read=0 written=0)

> Maybe I missed part of this discussion, but it seems a bit weird to have
> an option named "buffers" turn on a line that specifies numbers of
> "blocks".

Agreed, and I have to agree also with the people who have been
criticizing the output format. If we were trying to put the block
counts onto the same line as everything else then maybe parentheses
would be helpful, but here they're just clutter.

Perhaps

I/O: shared hit=96 read=1544 written=0 local hit=0 read=0 written=0 temp read=0 written=0

(although this would suggest making the option name "io" which is
probably a poor choice)

I also suggest that dropping out zeroes might help --- a large fraction
of EXPLAIN work is done with SELECTs that aren't ever going to write
anything. Then the above becomes

I/O: shared hit=96 read=1544

which is vastly more readable. You wouldn't want that to happen in
machine-readable formats of course, but I think we no longer care about
whether the text format is easy for programs to parse.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-10 15:49:33 Re: EXPLAIN BUFFERS
Previous Message Alvaro Herrera 2009-12-10 15:26:27 Re: EXPLAIN BUFFERS