On Wednesday February 9 2005 7:31, David Fetter wrote:
> On Wed, Feb 09, 2005 at 04:34:30PM -0700, Ed L. wrote:
> > Thinking about how to make this analysis faster and less
> > labor- intensive ...
> >
> > SELECT node_id, op, parent_node_id, index, relation,
> > cost_first, cost_last, cost_rows, cost_width,
> > actual_first, actual_last, actual_rows,
> > actual_loops, index_condition
> > FROM pg_explain_analyze('SELECT * FROM foo');
> >
> > Thankfully, I'm sure there are a lot of skilled
> > postgresql'ers just sitting around right now wishing they
> > had something to do.
>
> Well, I'm a little bored; I've got tomorrow off, and this
> seems like it might be doable in the kind of high-level
> PL/Foo's with which I'm familiar. What would the returning
> rowtype for
> pg_explain_analyze(TEXT) be?
LOL. If you're serious, I was thinking of something like this:
node_id integer not null unique
op varchar: "Index Scan"|"Hash Join"|"Seq Scan"|...
parent_node_id integer: node_id of parent node
index varchar: name of index for scan (oid better?)
relation varchar: name of relation for scan (oid better?)
cost_first float: first cost number
cost_last float: second cost number
cost_rows bigint
cost_width integer
actual_first float: time to first row
actual_last float: time to last row
actual_rows bigint
actual_loops bigint
condition varchar: what comes after "Index Cond:"|"Hash Cond:"|...
total_time float: total query time
How's that?
That might be a start. This is half-baked and you may be
the new head chef, so feel free.
Ed
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
