On Tue, 2006-06-06 at 10:43 -0400, Tom Lane wrote: > Simon Riggs <simon@xxxxxxxxxxxxxxx> writes: > > On Mon, 2006-06-05 at 17:06 -0400, Tom Lane wrote: > >> Well, it's a big query. If it ought to take a second or two, and > >> instead is taking an hour or two (1800 times the expected runtime), that > >> might be close enough to "never" to exhaust Chris' patience. Besides, > >> we don't know whether the 1800 might itself be an underestimate (too bad > >> Chris didn't provide EXPLAIN ANALYZE results). > > > This is a good example of a case where the inefficiency of EXPLAIN > > ANALYZE would be a contributory factor to it not actually being > > available for diagnosing a problem. > > Huh? The problem is the inefficiency of the underlying query. Of course that was the main problem from the OP. You mentioned it would be good if the OP had delivered an EXPLAIN ANALYZE; I agree(d). The lack of EXPLAIN ANALYZE is frequently because you can't get them to run to completion - more so when the query you wish to analyze doesn't appear to complete either. 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... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
