Tom Lane wrote:
daveg <[EMAIL PROTECTED]> writes:
I don't understand the motivation for so many connections by default, it
seems wasteful in most cases.
I think Andrew is thinking about database-backed Apache servers ...
Some quick checks say that CVS tip's demand for shared memory increases
by about 26kB per max_connection slot. (Almost all of this is lock table
space; very possibly we could afford to decrease max_locks_per_connection
when max_connections is large, to buy back some of that.) So boosting
the default from 100 to 400 would eat an additional 7.8mB of shared
memory if we don't do anything with max_locks_per_connection. This is
probably not a lot on modern machines.
A bigger concern is the increase in semaphores or whatever the local
platform uses instead. I'd be *real* strongly tempted to bound the
default at 100 on Darwin, for example, because on that platform each
"semaphore" is an open file that has to be passed down to every backend.
Uselessly large max_connections therefore slows backend launch and
risks running the whole machine out of filetable slots. I don't know
what the story is on Windows but it might have some problems with large
numbers of semas too --- anyone know?
Also, some more thought needs to be given to the tradeoff between
shared_buffers and max_connections. Given a constrained SHMMAX value,
I think the patch as-is will expend too much space on connections and
not enough on buffers --- the "* 5" in test_connections() probably needs
a second look.
All very good points. I didn't try to change the existing logic much.
I think we need to take this back to -hackers to get discussion on
tuning the way initdb selects the defaults.
Here are some questions:
. Do we want/need to make the behaviour platform specific?
. The patch put max_fsm_pages into the mix, and above it's suggested we
look at max_locks_per_connection. Is there anything else we should add?
My goal here is to pick reasonable defaults, not to tune the
installation highly. I think we tend to err on the side of being too
conservative today, but certainly it's possible to err the other way too.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
