sdv mailer <sdvmailer@yahoo.com> 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