Re: seq scan woes

Поиск
Список
Период
Сортировка
Искать
От
Dan Langille
Тема
Re: seq scan woes
Дата
Msg-id
40C493F8.1181.48F37175@localhost
Ответ на
Re: seq scan woes (Rod Taylor)
Список
Дерево обсуждения
seq scan woes "Dan Langille" <dan@langille.org>
Re: seq scan woes Rod Taylor <ports@rbt.ca>
Re: seq scan woes "Dan Langille" <dan@langille.org>
Re: seq scan woes Rod Taylor <ports@rbt.ca>
Re: seq scan woes "Dan Langille" <dan@langille.org>
Re: seq scan woes "Dan Langille" <dan@langille.org>
Re: seq scan woes "Dan Langille" <dan@langille.org>
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 по дате отправления
От: Dan Langille
Дата:
Сообщение: seq scan woes
От: Josh Berkus
Дата:
FAQ