From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Some queries starting to hang |
Date: | 2006-06-06 17:54:27 |
Message-ID: | 1149616467.25526.213.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, 2006-06-06 at 12:50, Craig A. James wrote:
> Tom Lane wrote:
> >>The idea I just had was: why do we need EXPLAIN ANALYZE to run to
> >>completion? In severe cases like this thread, we might be able to
> >>discover the root cause by a *partial* execution of the plan, as long as
> >>it was properly instrumented. That way, the OP might have been able to
> >>discover the root cause himself...
> >
> >
> > I don't think that helps, as it just replaces one uncertainty by
> > another: how far did the EXPLAIN really get towards completion of the
> > plan? You still don't have any hard data.
>
> But at least you have some data, which is better than no data. Even knowing that the plan got stuck on a particular node of the query plan could be vital information. For a query that never finishes, you can't even find out where it's getting stuck.
>
> That's why Simon's proposal might help in some particularly difficult situations.
Hmmmmm. I wonder if it be hard to have explain analyze have a timeout
per node qualifier? Something that said if it takes more than x
milliseconds for a node to kill the explain analyze and list the up to
the nasty node that's using all the time up?
That would be extremely useful.
From | Date | Subject | |
---|---|---|---|
Next Message | Mischa Sandberg | 2006-06-06 18:51:56 | Re: vacuuming problems continued |
Previous Message | Craig A. James | 2006-06-06 17:50:25 | Re: Some queries starting to hang |