From: | Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Roberto Mello <roberto(dot)mello(at)gmail(dot)com> |
Subject: | Re: [DOC] Add detail regarding resource consumption wrt max_connections |
Date: | 2024-01-12 22:14:38 |
Message-ID: | 170509767861.1131.15083983626399995184.pgcf@coridan.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation: tested, passed
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.
thank you
-----------------------
Cary Huang
Highgo Software Canada
www.highgo.ca
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-01-12 22:42:27 | Re: pg_upgrade failing for 200+ million Large Objects |
Previous Message | Jim Nasby | 2024-01-12 22:09:19 | Re: Make NUM_XLOGINSERT_LOCKS configurable |