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
Re: Proof-of-concept for initdb-time shared_buffers selection |
Список | 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 по дате отправления: