Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Robert Treat <rob@xzilla.net>
Cc: reid.thompson@crunchydata.com, Roberto Mello <roberto.mello@gmail.com>, Cary Huang <cary.huang@highgo.ca>, pgsql-hackers@lists.postgresql.org
Date: 2024-05-15T20:05:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Document that increasing max_connections uses more resources.

On Wed, May 15, 2024 at 4:00 PM Robert Treat <rob@xzilla.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?

-- 
Robert Haas
EDB: http://www.enterprisedb.com