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