On Thu, Dec 10, 2009 at 10:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@commandprompt.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.
Oooh, that's a nice idea, though I think you should throw in some commas if there is, say, both shared and local stuff: shared hit=96 read=1544, local read=19 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. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
