Re: Some queries starting to hang

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.

In response to

Browse pgsql-performance by date

  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