Re: Very high effective_cache_size == worse performance?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Very high effective_cache_size == worse performance?
Дата
Msg-id s2i603c8f071004201115xae430457q88074af464c8964f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Very high effective_cache_size == worse performance?  (David Kerr <dmk@mr-paradox.net>)
Ответы Re: Very high effective_cache_size == worse performance?  (David Kerr <dmk@mr-paradox.net>)
Список pgsql-performance
On Tue, Apr 20, 2010 at 2:03 PM, David Kerr <dmk@mr-paradox.net> wrote:
> that thought occured to me while I was testing this. I ran a vacuumdb -z
> on my database during the load and it didn't impact performance at all.

The window to run ANALYZE usefully is pretty short.  If you run it
before the load is complete, your stats will be wrong.  If you run it
after the select statements that hit the table are planned, the
updated stats won't arrive in time to do any good.

> I did turn on log_min_duration_statement but that caused performance to be unbearable,
> but i could turn it on again if it would help.

I think you need to find a way to identify exactly which query is
running slowly.  You could sit there and run "select * from
pg_stat_activity", or turn on log_min_duration_statement, or have your
application print out timestamps at key points, or some other
method...

...Robert

В списке pgsql-performance по дате отправления:

Предыдущее
От: Nikolas Everett
Дата:
Сообщение: Re: Very high effective_cache_size == worse performance?
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Very high effective_cache_size == worse performance?