Re: generic options for explain

On May 25, 2009, at 0:47 , Joshua Tolley wrote:

> On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
>> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
>>> On Sun, 24 May 2009, Pavel Stehule wrote:
>>>> we should have a secondary function explain_query(query_string,
>>>> option) that returns setof some.
>>
>>> +1. The incremental approach here should first be adding
>>> functions that
>>> actually do the work required. Then, if there's a set of those
>>> that look
>>> to be extremely useful, maybe at that point it's worth talking
>>> about how
>>> to integrate them into the parser. Starting with the parser changes
>>> rather than the parts that actually do the work is backwards. If
>>> you do
>>> it the other way around, at all times you have a patch that actually
>>> provides immediate useful value were it to be committed.
>>
>>> Something that returns a setof can also be easily used to
>>> implement the
>>> "dump EXPLAIN to a table" feature Josh Tolley brought up (which is
>>> another
>>> common request in this area).
>>
>> A serious problem with EXPLAIN via a function returning set, or with
>> putting the result into a table, is that set results are logically
>> unordered, just as table contents are. So from a strict point of
>> view
>> this only makes sense when the output format is designed to not
>> depend
>> on row ordering to convey information. We could certainly invent
>> such
>> a format, but I think it's a mistake to go in this direction for
>> EXPLAIN output that is similar to the current output.
>
> The Oracle version, as it fills the table of explain results, gives
> each number
> an id and the id of its parent row, which behavior we could
> presumably copy.

Or some other schema that allows us to preserve the tree.

Michael Glaesemann
grzm seespotcode net