Re: generic options for explain

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, "Dave Page" <dpage(at)pgadmin(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generic options for explain
Date: 2009-05-27 00:30:04
Message-ID: 4A1C433C.EE98.0025.1@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry to come in on this discussion so late. Just catching up....

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-05-27 01:18:58 commitfest management webapp
Previous Message Tom Lane 2009-05-26 23:47:45 Re: Common Table Expressions applied; some issues remain