Re: Understanding EXPLAIN ANALYZE output

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: David Fetter <david(at)fetter(dot)org>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Understanding EXPLAIN ANALYZE output
Date: 2005-02-10 03:07:03
Message-ID: 200502092007.03356.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Oisin Glynn 2005-02-10 03:11:19 Functions with more than 32 parameters
Previous Message Jan 2005-02-10 02:50:41 pg_affected Change Request