On Mon, May 25, 2009 at 8:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@enterprisedb.com> writes:
>> On Mon, May 25, 2009 at 11:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Admittedly this is a bit inconvenient, but the point is that the
>>> functionality does exist. There is no need to have a built-in
>>> version of this function unless we get significant advantages
>>> from having it built-in, and right now I'm not seeing those.
>
>> I assume people don't want the *text* of the current output format but
>> the actual values in separate columns.
>
> Well, I notice that everyone is carefully dodging the subject of exactly
> what columns they want,
I had a try at this upthread, actually, but it's not a real easy problem.
> but my example would clearly scale easily to any
> specific set of output columns that EXPLAIN might return instead of one
> text column. Since we were previously told that any particular release
> of PG need only offer one set of possible output columns, I figured the
> problem was solved ;-)
I was totally unconvinced by that argument.
I actually think that the best data structure for this would be
something like hstore. It would sure be nice to be able to manipulate
this data using SQL: I am sure there are people on this mailing list
who hate XML and maybe a few who hate JSON, but if they hate SQL then
they're off my list of people I care about making happy. :-) At the
same time, the variable number of output columns is problematic for a
flat table representation. It may not be so problematic that we can't
work around it, but it's definitely not great.
It's really the pits to think that our data model is so impoverished
that it can't in a reasonable way handle the output of our EXPLAIN
command. It would be awfully sweet to be able to do things like: show
me all the plan nodes where the expected and actual row counts
differed by more than a factor of 10. And why should I need an
external XML/JSON parser to do that, rather than just a WHERE clause?
...Robert