Re: Some queries starting to hang

From: Chris Beecroft <CBeecroft(at)PrO-Unlimited(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Some queries starting to hang
Date: 2006-06-05 22:22:00
Message-ID: 1149546120.8606.76.camel@bg002441.pro-unlimited.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, 2006-06-05 at 14:06, Tom Lane wrote:
> Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> > On Mon, Jun 05, 2006 at 04:07:19PM -0400, Tom Lane wrote:
> >> I'm wondering about out-of-date or nonexistent ANALYZE stats, missing
> >> custom adjustments of statistics target settings, etc.
>
> > But even the nested loop shouldn't be a "never returns" case, should
> > it? For 1800 rows?
>
> 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). The hash plan will scale
> to larger numbers of rows much more gracefully than the nestloop ...
>
> regards, tom lane

Hello,

If anyone is curious, I've attached an explain analyze from the now
working replicated database. Explain analyze did not seem return on the
'broken' database (or at least, when we originally tried to test these,
did not return after an hour and a half, which enough time to head right
past patient into crabby...)

Chris

Attachment Content-Type Size
explain.out text/plain 6.9 KB

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dan Libby 2006-06-06 00:03:59 Problem: query becomes slow when calling a fast user defined function.
Previous Message Josh Berkus 2006-06-05 21:26:56 Re: How to force Postgres to use index on ILIKE