Re: [DOC] Add detail regarding resource consumption wrt max_connections
Robert Treat <rob@xzilla.net>
From: Robert Treat <rob@xzilla.net>
To: Robert Haas <robertmhaas@gmail.com>
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:22:43Z
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 →
-
Document that increasing max_connections uses more resources.
- 8ba346283335 17.0 landed
On Wed, May 15, 2024 at 4:05 PM Robert Haas <robertmhaas@gmail.com> wrote: > > 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? > 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