On Thu, Jan 20, 2011 at 11:55 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> The main problem I've got with this patch is that there's no place to
>> shoehorn the information into the textual EXPLAIN format without
>> breaking a lot of expectations (and hence code --- it's insane to
>> imagine that any significant amount of client-side code has been
>> rewritten to make use of xml/json output yet). It would be nice to know
>> what other requests are likely to be coming down the pike before we
>> decide exactly how we're going to break things.
>
> While I agree completely about the general "if you're going to break,
> break it big" approach, but I don't particularly care for holding output
> strings from EXPLAIN to the same level that we do the wireline protocol.
> This is going into a new major version, not something which is being
> back-patched, and users now have a way in a released version to get away
> from relying on the string output.
I agree; we make bigger changes than this all the time. At the risk
of putting words in Tom's mouth, I think part of the concern here may
be that the EXPLAIN output is quite verbose already, and adding a few
more details is going to make it harder to read in the cases where you
*don't* care about this additional information. That's a valid
concern, but I don't know what to do about it - not having this
information available isn't better. It's tempting to propose moving
the "actual" numbers down to the next line, so that the lines aren't
so ridiculously long.
Looking at the patch, I have to say I had hoped this was going to show
nfiltered in both the estimated and actual cases, which it doesn't.
Now maybe that's more work than we want to put in, but it would be
nice to have.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company