| From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: EXPLAIN ANALYZE |
| Date: | 2006-12-13 19:46:47 |
| Message-ID: | 20061213194646.GL6551@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > Well, I'd like a way of making EXPLAIN ANALYZE return something
> > useful within a reasonable amount of time. We can define that as the
> > amount of time that the user considers is their goal for the query.
>
> What sort of "useful" results would you expect to be able to see from
> such an aborted EXPLAIN ANALYZE? I cannot quite imagine what
> instructive value a partially executed plan output would have. It's
> not like we can somehow ensure executing an equal proportion of each
> plan node or something. Do you have a specific case in mind?
The query is most likely to get canceled while it is working on whatever
node in the plan is the bottleneck, and it's likely going to be easy to
spot since nodes above it wouldn't have gotten much done.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Reich | 2006-12-13 19:50:21 | Re: EXPLAIN ANALYZE |
| Previous Message | Simon Riggs | 2006-12-13 19:36:50 | pg_standby and build farm |