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