MIME-Version: 1.0
References: <CAKz==bJBCWrvN77fmuZ2XqD3jazWEb=E80AA4Yv9C9tQ61YDdQ@mail.gmail.com>
 <170509767861.1131.15083983626399995184.pgcf@coridan.postgresql.org>
In-Reply-To: <170509767861.1131.15083983626399995184.pgcf@coridan.postgresql.org>
From: Roberto Mello <roberto.mello@gmail.com>
Date: Sat, 13 Jan 2024 10:31:42 -0700
Message-ID: <CAKz==bLJAwDGMMRqJSwA0Y+h10OYff73cd1pNCyzGnwYLq74BA@mail.gmail.com>
Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
To: Cary Huang <cary.huang@highgo.ca>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fb921d060ed72822"
Archived-At: <https://www.postgresql.org/message-id/CAKz%3D%3DbLJAwDGMMRqJSwA0Y%2Bh10OYff73cd1pNCyzGnwYLq74BA%40mail.gmail.com>
Precedence: bulk

--000000000000fb921d060ed72822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 12, 2024 at 3:15=E2=80=AFPM Cary Huang <cary.huang@highgo.ca> w=
rote:

> 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 mea=
ns
> 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

--000000000000fb921d060ed72822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jan 12, 2024 at 3:15=E2=80=AFPM C=
ary Huang &lt;<a href=3D"mailto:cary.huang@highgo.ca">cary.huang@highgo.ca<=
/a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">I think it is good to warn the user about the increas=
ed allocation of memory for certain parameters so that they do not abuse it=
 by setting it to a huge number without knowing the consequences.<br>
<br>
It is true that max_connections can increase the size of proc array and oth=
er resources, which are allocated in the shared buffer, which also means le=
ss shared buffer to perform regular data operations. I am sure this is not =
the only parameter that affects the memory allocation. &quot;max_prepared_x=
acts&quot; can also affect the shared memory allocation too so the same war=
ning message applies here as well. Maybe there are other parameters with si=
milar effects. <br>
<br>
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 &quot;shared_buffers&quot; setting as well.=
<br></blockquote><div><br></div><div>Appreciate the review, Cary.</div><div=
><br></div><div>My goal was to inform the reader that there are implication=
s to setting max_connections higher. I&#39;ve personally seen a user mindle=
ssly set this to 50k connections, unaware it would cause unintended consequ=
ences. <br></div><div><br></div><div>I can add a suggestion for the user to=
 consider increasing shared_buffers in accordance with higher max_connectio=
ns, but it would be better if there was a &quot;rule of thumb&quot; guideli=
ne to go along. I&#39;m open to suggestions.</div><div><br></div><div>I can=
 revise with a similar warning in max_prepared_xacts as well.</div><div><br=
></div><div>Sincerely,</div><div><br></div><div>Roberto<br></div></div></di=
v>

--000000000000fb921d060ed72822--