Re: Postgres 7.3.1 poor insert/update/search performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Postgres 7.3.1 poor insert/update/search performance
Дата
Msg-id 19952.1043251798@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Postgres 7.3.1 poor insert/update/search performance  (Brian Hirt <bhirt@mobygames.com>)
Список pgsql-performance
Brian Hirt <bhirt@mobygames.com> writes:
> So my question is:  if the kernel is caching all this data, what's the
> benefit of setting this to 1000 or higher?   Why wouldn't i just set it
> to 0 if I believe my kernel is doing a good job.

Well, setting it to 0 won't work ;-).  There's some minimum number of
buffers needed for PG to work at all; depending on complexity of your
queries and number of active backends it's probably around 25-100.
(You'll get "out of buffers" failures if too few.)  But more to the
point, when shared_buffers is too small you'll waste CPU cycles on
unnecessary data transfers between kernel and user memory.  It seems to
be pretty well established that 64 is too small for most applications.
I'm not sure how much is enough, but I suspect that a few thousand is
plenty to get past the knee of the performance curve in most scenarios.

            regards, tom lane

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

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Postgres 7.3.1 poor insert/update/search performance
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: [GENERAL] optimizing query