Re: seq scan woes
От | Dan Langille |
---|---|
Тема | Re: seq scan woes |
Дата | |
Msg-id | 40C493F8.1181.48F37175@localhost обсуждение исходный текст |
Ответ на | seq scan woes ("Dan Langille" <dan@langille.org>) |
Ответы |
Re: seq scan woes
|
Список | 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/
В списке pgsql-performance по дате отправления: