daveg <daveg@sonic.net> 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.
regards, tom lane
