Re: New server to improve performance on our large and busy DB - advice?

Поиск
Список
Период
Сортировка
От Carlo Stonebanks
Тема Re: New server to improve performance on our large and busy DB - advice?
Дата
Msg-id hjcnp4$m8f$1@news.hub.org
обсуждение исходный текст
Ответ на Re: New server to improve performance on our large and busy DB - advice?  ("Carlo Stonebanks" <stonec.register@sympatico.ca>)
Ответы Re: New server to improve performance on our large and busy DB - advice?
Список pgsql-performance
Hi Greg,

As a follow up to this suggestion:

>> I don't see effective_cache_size listed there.  If that's at the default,
>> I wouldn't be surprised that you're seeing sequential scans instead of
>> indexed ones far too often.

I found an article written by you
http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm and thought
this was pretty useful, and especially this comment:

<<effective_cache_size should be set to how much memory is leftover for disk
caching after taking into account what's used by the operating system,
dedicated PostgreSQL memory, and other applications. If it's set too low,
indexes may not be used for executing queries the way you'd expect. Setting
effective_cache_size to 1/2 of total memory would be a normal conservative
setting. You might find a better estimate by looking at your operating
system's statistics. On UNIX-like systems, add the free+cached numbers from
free or top. On Windows see the "System Cache" in the Windows Task Manager's
Performance tab.
>>

Are these values to look at BEFORE starting PG? If so, how do I relate the
values returned to setting the effective_cache_size values?

Carlo

PS Loved your 1995 era pages. Being a musician, it was great to read your
recommendations on how to buy these things called "CD's". I Googled the
term, and they appear to be some ancient precursor to MP3s which people
actually PAID for. What kind of stone were they engraved on? ;-D



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

Предыдущее
От: DM
Дата:
Сообщение: Re: Fragmentation/Vacuum, Analyze, Re-Index
Следующее
От: Tory M Blue
Дата:
Сообщение: Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL