Re: generic options for explain - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: generic options for explain
Date
Msg-id 4A1C433C.EE98.0025.1@wicourts.gov
Whole thread Raw
In response to Re: generic options for explain  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: generic options for explain  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
Sorry to come in on this discussion so late.  Just catching up....
Robert Haas <robertmhaas@gmail.com> wrote: 
> Responding to these in bulk, I think that 1, 3, and 4 are pretty
> convincing arguments that the SQL-based output format is
> underspecified.  I hereby promise not to do anything about that
> without further discussion, which is an easy promise to make
> considering that in light of those comments I have no idea what it
> should look like.  I think (1) is the most damning point.  However,
> as far as I can see, none of these will affect XML or JSON.
Personally, I find XML to be very hard to read; however, I can see the
value of writing to that and having someone who can tolerate XSLT turn
XML into anything else we want.  (That could include morphing it into
SELECT statements with the literals to present it as a tuple set, I
should think.)  As long as nobody considers this issue "done" until
there are useful and convenient ways to display and use the data
within psql without having to look at the XML, that seems a reasonable
approach.
The big plus of the current technique is that it is so convenient to
Ctrl+C something which is running too long, arrow up, hit Home, and
put the EXPLAIN word in front.  Turning the query into a character
string literal and feeding it to a function would be a big step
backward.
A big down side of the current technique is that you can't get both
the results of a SELECT and its plan.  I haven't seen any discussion
here about emitting the EXPLAIN output through some INFO messages or
some such, and letting the query return its normal results, but I feel
that would be a significant improvement, if it that be done.
Also, something I miss from previous database products is a way to
control the verbosity of the output when planning.  I do think that
needs to be some sort of option up front, not a filter phase, because
of the high cost it can have.  If there was a way to show all the
candidate plans and their cost estimates in a run time environment,
without any special build or configuration needed, I'd use it every
now and then.
-Kevin


pgsql-hackers by date:

Previous
From: Caleb Welton
Date:
Subject: [PATCH] plpythonu datatype conversion improvements
Next
From: Robert Haas
Date:
Subject: commitfest management webapp