Re: Proof-of-concept for initdb-time shared_buffers selection

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: Proof-of-concept for initdb-time shared_buffers selection
Дата
Msg-id 5fqhivovt411oqkn828tu24u0lqhcrvs6l@4ax.com
обсуждение исходный текст
Ответ на Proof-of-concept for initdb-time shared_buffers selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proof-of-concept for initdb-time shared_buffers selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proof-of-concept for initdb-time shared_buffers selection  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>The attached patch shows how initdb can dynamically determine reasonable
>shared_buffers and max_connections settings that will work on the
>current machine.

Can't this be done on postmaster startup?  I think of two GUC
variables where there is only one today: min_shared_buffers and
max_shared_buffers.  If allocation for the max_ values fails, the
numbers are decreased in a loop of, say, 10 steps until allocation
succeeds, or even fails at the min_ values.

The actual values chosen are reported as a NOTICE and can be inspected
as readonly GUC variables.

This would make the lives easier for the folks trying to come up with
default .conf files, e.g.
  min_shared_buffers = 64
  max_shared_buffers = 2000
could cover a fairly large range of low level to mid level machines.

A paranoid dba, who doesn't want the postmaster to do unpredictable
things on startup, can always set min_xxx == max_xxx to get the
current behaviour.

Servus
 Manfred

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: followup on previous