> 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. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly