| From: | Joshua Reich <josh(at)root(dot)net> |
|---|---|
| To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, 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:50:21 |
| Message-ID: | 4580597D.6060801@root.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thumbs up on this from a lurker.
I recall a previous post about some sort of "progress bar" hack that
would show you where in a plan a currently executing query was at. Has
any work been done on this?
Josh Reich
Jim C. Nasby wrote:
> 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.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2006-12-13 19:52:11 | Re: recovery.conf parsing problems |
| Previous Message | Jim C. Nasby | 2006-12-13 19:46:47 | Re: EXPLAIN ANALYZE |