Re: machine-readable explain output v4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: machine-readable explain output v4
Date: 2009-08-10 05:56:47
Message-ID: 15639.1249883807@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Revised patch attached. I'm not convinced this is as good as it can
> be, but I've been looking at this patch for so long that I'm starting
> to get cross-eyed, and I'd like to Tom at least have a look at this
> and assess it before we run out of CommitFest.

Committed after significant hacking to try to make the format
abstraction layer a tad more complete.

There are still some open issues:

* I still think we need a written spec for the non-text output formats.
One of the problems with machine reading of the text format is you have
to reverse-engineer what the possibilities are, and this patch hasn't
made that better. A list of the possible fields, and the possible
values for those fields that have finite domains, would be a start.

* 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.

* 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.

* 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.

Anyway, it's committed so that people can play with it. We're a
lot more likely to get feedback if people actually try to use the
feature.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-08-10 06:00:27 Re: Patch for 8.5, transformationHook
Previous Message Jaime Casanova 2009-08-10 05:39:17 Re: pg_stat_activity.application_name