Re: Some belated patch review for "Buffers" explain analyze patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Josh Berkus <josh(at)agliodbs(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some belated patch review for "Buffers" explain analyze patch
Date: 2010-02-10 03:59:50
Message-ID: 603c8f071002091959q23e006afkcbf9e352791aad53@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 9, 2010 at 10:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... I wouldn't object to adding a "total time" field to the
>>> machine-readable formats.
>
>> One possibility we discussed previously is to add some decimal places
>> to the relevant values when nloops > 1.
>
> Hmm, I must've missed that conversation, but it seems like a possibly
> workable compromise.

http://archives.postgresql.org/pgsql-hackers/2009-05/msg01419.php

>> If we're going to add a total time field, I think we should add it to
>> both the machine-readable and human-readable formats.  I know it's a
>> little long-winded, but one of the things that I find really
>> unfortunate about the current format is that it's sometimes hard to
>> look at a plan tree and figure out where "the slow part" is, because
>> some things have been divided through by the number of loops.  Reading
>> through the JSON or YAML format to find the data is, I guess, better
>> than nothing, but only slightly: I frequently deal with plans that are
>> 25-30 lines long: in XML format, those will be 250-300 lines long.  I
>> wouldn't mind having to do EXPLAIN (ANALYZE, VERBOSE) or EXPLAIN
>> (ANALYZE, some-other-option) to get the details, but EXPLAIN (ANALYZE,
>> FORMAT XML) ... is not really a direction I want to go.
>
> I don't really buy this line of reasoning.  You don't want to read the
> XML format because it's too long, so your solution is to make the text
> format longer?

Yes. We could add every bell and whistle imaginable to the text
format and it still would not begin to approach the verbosity of the
machine-readable formats. Have you looked at them on a complex plan?
They are really, really long, and in many cases quite unreadable by
human beings. That's OK, because that's not what they're for. But do
I want a format this IS intended to be readable by human beings and
also contains all the relevant information? Definitely.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Takahiro Itagaki 2010-02-10 04:11:08 Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore
Previous Message Andrew Dunstan 2010-02-10 03:53:50 Re: CVS checkout source code for different branches