Re: machine-readable explain output v2 - Mailing list pgsql-hackers

On Sat, Jul 18, 2009 at 10:29 PM, Andres Freund<andres@anarazel.de> wrote:
> One part where I find the code flow ugly is 'did_boilerplate' in
> report_triggers/its callsites.
> I can see why it is done that way, but its not exactly obvious to read when
> you want to find out how the format looks.

Suggestions?

> Another, minor, issue is that the patch changes the FORMAT TEXT/default output
> if VERBOSE is specified (schema is added). I don't see that as a real problem
> because the format for VERBOSE is new anyway, but I thought I would mention
> it.

Verbose isn't new, but in 8.4 all it does is displays the output list
for each node.  I think there's room for verbose to include some other
types of verbosity that don't merit their own options.

I think that the choice of what information to display shouldn't
depend on what format you use to display it.  The funny thing about me
being the one to implement XML and JSON output is that I don't
actually want to use them for anything - and especially not XML.  I
implemented them because they were a good (and popular) test case for
the options facility, but they're not actually the options I want.
And if I or others add functionality in the future to gather more
information via EXPLAIN, I don't want to have to use XML or JSON to
get at them.

> XML Format:
> As discussed previously I would like the format to look a bit different - but
> everyone wants it to look different anyway, so I think its ok as one of
> multiple possible lowest common determinators... With the big advantage of
> already being implemented.

Yes, I think there's not much advantage to changing this around.
There are lots of people with lots of ideas on this, but they're all
different and AFAICS there's no clear pattern.  I think it's good to
try to match the text output as much as possible.

> I think it would be nice in the future to add some sort of
> 'category={planner,timing,..}' attribute, but I think that should be
> discussed/implemented separately.

Agree that there are more things to be added.  But I haven't taken the
time to figure out exactly what.  One of things I would really like to
be able to get is the number of buckets and batches (expected and
actual) for a hash join.  Other things I've wished for:

- number of tuples discarded by a filter condition on a particular node
- amount of time spent constructing the output list of a node as
opposed to the rest of what the node does

> Documentation:
> I think it would be nice to add some more documentation about the xml format
> for application writers, but I think this should be a separate patch anyway.

Suggestions?

I have posted a new version of this patch on a separate thread; do you
have time to re-review?

...Robert