Re: [DOC] Add detail regarding resource consumption wrt max_connections

Поиск
Список
Период
Сортировка
От Roberto Mello
Тема Re: [DOC] Add detail regarding resource consumption wrt max_connections
Дата
Msg-id CAKz==bLJAwDGMMRqJSwA0Y+h10OYff73cd1pNCyzGnwYLq74BA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [DOC] Add detail regarding resource consumption wrt max_connections  (Cary Huang <cary.huang@highgo.ca>)
Ответы Re: [DOC] Add detail regarding resource consumption wrt max_connections  (reid.thompson@crunchydata.com)
Список pgsql-hackers
On Fri, Jan 12, 2024 at 3:15 PM Cary Huang <cary.huang@highgo.ca> wrote:
I think it is good to warn the user about the increased allocation of memory for certain parameters so that they do not abuse it by setting it to a huge number without knowing the consequences.

It is true that max_connections can increase the size of proc array and other resources, which are allocated in the shared buffer, which also means less shared buffer to perform regular data operations. I am sure this is not the only parameter that affects the memory allocation. "max_prepared_xacts" can also affect the shared memory allocation too so the same warning message applies here as well. Maybe there are other parameters with similar effects.

Instead of stating that higher max_connections results in higher allocation, It may be better to tell the user that if the value needs to be set much higher, consider increasing the "shared_buffers" setting as well.

Appreciate the review, Cary.

My goal was to inform the reader that there are implications to setting max_connections higher. I've personally seen a user mindlessly set this to 50k connections, unaware it would cause unintended consequences.

I can add a suggestion for the user to consider increasing shared_buffers in accordance with higher max_connections, but it would be better if there was a "rule of thumb" guideline to go along. I'm open to suggestions.

I can revise with a similar warning in max_prepared_xacts as well.

Sincerely,

Roberto

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recovering from detoast-related catcache invalidations
Следующее
От: Dmitry Koval
Дата:
Сообщение: Re: collect_corrupt_items_vacuum.patch