Re: machine-readable explain output v2

On Friday 31 July 2009 23:13:54 Robert Haas wrote:
> On Sat, Jul 18, 2009 at 10:29 PM, Andres Freund<andres(at)anarazel(dot)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?
Will take a look when looking at the whole patch again.

> > 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.
Well, before 8.4 it was something entirely different... So its kinda "new".

> 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.
I am not particularly interested in XML itself as well. Just as yours my main
interest is having the possibility to add information without causing wreckage
all over the place....
Although for some of the more complex queries (And as you know I have some
rather ugly/complex ones...) a graphical viewer of the plans might be nice.

I am quite happy that the annoyance over a patch of mine "helped" you starting
to work on this ;-)
Thanks for all the work.

> > 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:
I think after the patch is committed there should be a big collection of
wishes so we can see what further infrastructure work is going to be needed...
Depending on the amount and kind of different options it might not be sufficient
to simply extent struct Instrumentation/the current instrumentation
infrastructure...

> > 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 think extending, correcting and commenting a schema like the one I provided
sometime ago would be a good start. Anybody wanting to use the output should
be familiar enough with that...
I can try to do some of that if somebody goes over my english afterwards...

Andres