From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Some queries starting to hang |
Date: | 2006-06-06 21:14:48 |
Message-ID: | 1149628487.25526.228.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, 2006-06-06 at 16:11, Tom Lane wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> > The cost of not aborting on the first sort is that you may never see
> > what the part of the plan is that's killing your query, since you never
> > get the actual plan.
>
> Well, you can get the plan without waiting a long time; that's what
> plain EXPLAIN is for. But I still disagree with the premise that you
> can extrapolate anything very useful from an unfinished EXPLAIN ANALYZE
> run. As an example, if the plan involves setup steps such as sorting or
> loading a hashtable, cancelling after a minute might make it look like
> the setup step is the big problem, distracting you from the possibility
> that the *rest* of the plan would take weeks to run if you ever got to
> it.
Sure, but it would be nice to see it report the partial work.
i.e. I got to using a nested loop, thought there would be 20 rows,
processed 250,000 or so, timed out at 10 minutes, and gave up.
I would find that useful.
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2006-06-06 23:27:16 | Re: lowering priority automatically at connection |
Previous Message | Tom Lane | 2006-06-06 21:11:14 | Re: Some queries starting to hang |