sdv mailer <[EMAIL PROTECTED]> writes: > Forking consumes a large amount of CPU when you have > many simultaneous connections and adds up to the > latency. Particularly MySQL users may think > PostgreSQL's connection time is much slower because > these users tend to perform relatively simple queries.
Frankly I think part of the reason you'll get little traction on this front is that some people consider an application that puts building a database connection into a critical path, especially one that does only a single simple query and disconnects, a stupid design. If it's a connection time is critical element it's trivial to move it outside the critical path and reuse connections. You'll get much better performance that way as well since both Postgres and Linux will have more time to observe how the process behaves and adjust cache and schedule behaviour. > In my case, connection pooling and persistent > connection is useless for a large server farm > consisting of hundreds of partitioned and replicated > servers doing only simple queries. Well have you tried either? It would involve having a lot more idle connections but then that's effectively the same as "preforking" anyways. Not only would they be "preforked" but they wouldn't have to be shut down and recreated repeatedly at all, even outside the critical path. If the idle connections consume too much memory to be feasible (like, say, if you have thousands of database servers but only a small unpredictable subset of which are busy at any time) then "preforking" wouldn't really help much either and suffer the same problem. -- greg ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
