From: | "Dan Langille" <dan(at)langille(dot)org> |
---|---|
To: | Rod Taylor <ports(at)rbt(dot)ca> |
Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: seq scan woes |
Date: | 2004-06-07 20:12:40 |
Message-ID: | 40C493F8.1181.48F37175@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 7 Jun 2004 at 16:00, Rod Taylor wrote:
> On Mon, 2004-06-07 at 15:45, Dan Langille wrote:
> > A production system has had a query recently degrade in performance.
> > What once took < 1s now takes over 1s. I have tracked down the
> > problem to a working example.
>
> What changes have you made to postgresql.conf?
Nothing recently (ie. past few months). Nothing at all really.
Perhaps I need to start tuning that.
> Could you send explain analyse again with SEQ_SCAN enabled but with
> nested loops disabled?
See http://rafb.net/paste/results/zpJEvb28.html
13s
> Off the cuff? I might hazard a guess that effective_cache is too low or
> random_page_cost is a touch too high. Probably the former.
I grep'd postgresql.conf:
#effective_cache_size = 1000 # typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch cost
NOTE: both above are commented out.
Thank you
--
Dan Langille : http://www.langille.org/
BSDCan - http://www.bsdcan.org/
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-06-07 20:31:37 | Re: is it possible to for the planner to optimize this form? |
Previous Message | Rod Taylor | 2004-06-07 20:00:28 | Re: seq scan woes |