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:19:05
Message-ID: 200502092019.05840.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday February 9 2005 8:07, Ed L. wrote:
> >
> > 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

You might drive the rowtype by what you (alias I) hope to get out
of it: 1) easy discovery of the slowest parts of the query, 2)
really slow avg row retrieval times (like the 4.63ms/row
discussed earlier in this thread), and I don't know what else.
Part 2 seems straight forward with this scheme, less sure about
part 1.

Ed

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jonel Rienton 2005-02-10 03:22:54 Re: Postgresql and Macintosh
Previous Message Oisin Glynn 2005-02-10 03:11:19 Functions with more than 32 parameters