Re: [HACKERS] machine-readable explain output v2
On Sat, Jul 18, 2009 at 10:29 PM, Andres Freundand...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v2
Hi Robert, On Friday 31 July 2009 23:13:54 Robert Haas wrote: On Sat, Jul 18, 2009 at 10:29 PM, Andres Freundand...@anarazel.de wrote: I have posted a new version of this patch on a separate thread; do you have time to re-review? Yes, I have seen it. I plan to spent some time on it tonight and/or tomorrow. You havent pushed out to your git mirror? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 Freundand...@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?
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v2
On Fri, Jul 31, 2009 at 6:04 PM, Andres Freundand...@anarazel.de wrote:
I am quite happy that the annoyance over a patch of mine helped you starting
to work on this ;-)
Thanks for all the work.
You're welcome, thanks for all your reviewing. For the record, I
wasn't annoyed BY the patch; I was annoyed by the inability of the
patch to be applied.
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...
We'll have to see. The basic options framework is already in, but I
think a more far-ranging discussion should wait until post-CommitFest,
whether explain (format ...) ... is committed by then or not.
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...
Happy to copy-edit.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v2
On Fri, Jul 31, 2009 at 5:36 PM, Andres Freundand...@anarazel.de wrote: Hi Robert, On Friday 31 July 2009 23:13:54 Robert Haas wrote: On Sat, Jul 18, 2009 at 10:29 PM, Andres Freundand...@anarazel.de wrote: I have posted a new version of this patch on a separate thread; do you have time to re-review? Yes, I have seen it. I plan to spent some time on it tonight and/or tomorrow. You havent pushed out to your git mirror? Ah, fixed. Sorry, forgot I made a new local branch. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v2
Hi Robert, Hi All, On Sunday 19 July 2009 04:29:42 Andres Freund wrote: I did not yet look at the contrib/autoexplain portions. Will do that on Monday or so. Early Monday: Looks fine, except that the new auto_explain.log_format parameter is not documented. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
