> And "preforking" makes this different, how ? Perhaps having a pool of
> processes ready to be handed a query to a specific database, where you
> configure N connections to db1, M to db2 etc. still means lots of resource
> usage. In effect a preforked database server *is* an idle connection, just
> without the TCP establishment and teardown sequence which is negligable on
> modern platforms - and even if it were not negligable, it would be
> effectively identical regardless of the chosen DB platform.
In theory, it should drastically reduce the number of idle connections
for poor connection pooling on the other end.
The problem are pools for Apache that establish 1 connection per Apache
backend. 100 Apache backends means 100 backend connections (50 of which
may be idle as not all pages use the database). Multiply that by 40
webservers and you have a real mess of idle connections.
Cutting that count down to 10 idlers in total by having PostgreSQL
prefork a specific database would make a significant difference.
The other (preferable) alternative is to convince Apache to use a common
connection pool per server rather than per Apache backend.