Re: machine-readable explain output v4

On Mon, Aug 10, 2009 at 10:54 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Aug 10, 2009 at 1:56 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> There are still some open issues:
>>>
>>> * I still think we need a written spec for the non-text output formats.
>
>> Where would we put this in the documentation?  Seems like it might
>> need a new section/chapter somewhere.
>
> I think it'd be sufficient to put it on the EXPLAIN reference page.
> IIRC, the COPY data format is documented on COPY's reference page,
> and this is equally particular to a single SQL command.

OK, I was just worried it might be long.

>>> * There are some decisions that seem a bit questionable to me, like
>>> using "Parent Relationship" tags rather than having the child plans
>>> as labeled attributes of the parent node.  But I can't really evaluate
>>> this for lack of experience with designing XML/JSON structures.
>
>> That would work for XML, but I think it doesn't for JSON.
>
> Why not?  Something like
>
>        "Inner": { ... }
>
> fits in JSON AFAICS.  I don't know if there are any recognized style
> guidelines in the structured-document world that would approve or
> deprecate the way you've done it.  I do see the advantage that code
> can visit all the subplans of a plan without knowing much about the
> plan tree structure.  What's bothering me the most is that member
> subplans of an Append are mushed together with other child plan types.
> The ordering of the members is significant.  Now the chosen
> representation does preserve that order, but ISTM mushing all the
> child plan types together like this makes it *look* like the Plans
> attribute is unordered; especially when the ordering is in fact
> not significant for every other child plan type.

Oh, I see what you mean. Yeah, we could do that, and I thought about
it. I decided on this, because it would potentially let you recurse
down the tree of nodes without having to handle every kind of
sub-plan-node separately.

>>> * As already noted, the URL for the XML schema seems questionable.
>>> I think that versioning should go more like v1, v2, ... instead of
>>> being tied to a year.
>
>> Or what about being based on the major PostgreSQL major version?
>> Would it be lame to think about something like
>> http://www.postgresql.org/docs/8.5/static/sql-explain.html ?
>
> Yeah.  In the first place, I imagine the schema will change a few times
> before 8.5 is released.  In the second, once we do get it right it'll
> probably be stable across multiple releases.  I think we should just
> have a serial number on them, and not assume that either years or
> releases are appropriate quantifiers.

That's fine then. I'm easy; the schema URL is the least interesting
part of this IMO.

>>> * I complained earlier that I thought dumping expressions as text
>>> was pretty bogus --- it'll leave anything that's trying to
>>> do analysis in depth still having to parse complicated stuff.
>>> I don't know exactly what I want instead, but at the very least it
>>> seems like the variables used in an expression ought to be more
>>> readily available.
>
> On this point: basically what's bothering me is that by dumping
> expressions as undifferentiated text blobs, we are making the same
> mistake in small that this patch is meant to solve in large.
> I don't really want to do the work of decomposing expressions right
> now, but I'm not happy that it's impossible to do so without a
> non-backwards-compatible DTD break.  What do you think of emitting
> expressions as containers, with the text as the only property?
> Instead of
>
>        <Filter>(f1 &gt; 0)</Filter>
>
> something like
>
>        <Filter><Expr><Text>(f1 &gt; 0)</Text></Expr></Filter>
>
> This would leave room to add additional properties beside the text,
> and not break existing clients when we do it.

Well, there you seem to be adding TWO containers, which is probably
overkill. I could see adding one.

> Another issue that bothers me a bit is the "Strategy" field.
> It may or may not appear depending on "Node Type", and when it
> does appear, the possible values vary depending on "Node Type".
> Is that sort of non-orthogonality considered good style?

It is in the land of Robert, but someone else might prefer something
different. I'm not attached to doing it this way, but as a guy who
does a lot of database work I tend to prefer to avoid having a
multiple, distinct fields for similar information. It makes it had to
read the SELECT * FROM table output in my 80-character terminal
window. :-)

...Robert