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

From: Robert Treat <rob(at)xzilla(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: reid(dot)thompson(at)crunchydata(dot)com, Roberto Mello <roberto(dot)mello(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
Date: 2024-05-15 20:22:43
Message-ID: CAJSLCQ03WeQ0C_sGTH8yztNWS2sGZJGZmAZJ+Qx3s5Ed95F1pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 15, 2024 at 4:05 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, May 15, 2024 at 4:00 PM Robert Treat <rob(at)xzilla(dot)net> wrote:
> > I think the only unresolved question in my mind was if we should add a
> > similar note to the original patch to max_prepared_xacts as well; do
> > you intend to do that?
>
> I didn't intend to do that. I don't think it would be incorrect to do
> so, but then we're kind of getting into a slippery slope of trying to
> label every parameter that has increases shared memory usage or any
> other kind of research consumption, and there are probably (pulls
> number out of the air) twenty of those. It seems more worthwhile to
> mention it for max_connections than the other (deducts one from
> previous random guess) nineteen because it affects a whole lot more
> things, like the size of the fsync queue and the size of the lock
> table, and also because it tends to get set to relatively large
> values, unlike, for example, autovacuum_max_workers. If you think we
> should go further than just doing max_connections, then I think we
> either need to (a) add a note to every single bloody parameter that
> affects the size of shared memory or (b) prove that the subset where
> we add such a note have a significantly larger impact than the others
> where we don't. Do you think we should get into all that?
>

Nope. Let's do the best bang for the buck improvement and we can see
if we get any feedback that indicates more needs to be done.

Robert Treat
https://xzilla.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-05-15 20:23:23 Re: Why does pgindent's README say to download typedefs.list from the buildfarm?
Previous Message Nathan Bossart 2024-05-15 20:21:36 Re: More performance improvements for pg_dump in binary upgrade mode