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

From: Roberto Mello <roberto(dot)mello(at)gmail(dot)com>
To: Cary Huang <cary(dot)huang(at)highgo(dot)ca>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
Date: 2024-01-13 17:31:42
Message-ID: CAKz==bLJAwDGMMRqJSwA0Y+h10OYff73cd1pNCyzGnwYLq74BA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 12, 2024 at 3:15 PM Cary Huang <cary(dot)huang(at)highgo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Koval 2024-01-13 17:33:10 Re: collect_corrupt_items_vacuum.patch
Previous Message Tom Lane 2024-01-13 17:18:32 Re: Recovering from detoast-related catcache invalidations