Neil Conway wrote: > Furthermore, IIRC PostgreSQL's relatively slow connection creation time > has as much to do with other per-backend initialization work as it does > with the time to actually fork() a new backend. If there is interest in > optimizing backend startup time, my guess would be that there is plenty > of room for improvement without requiring the replacement of processes > with threads.
I see there is a whole TODO Chapter devoted to the topic. There is the idea of pre-forked and persistent backends. That would be very useful in an environment where it's quite hard to use connection pooling. We are currently working on a mail system for a free webmail. The mda (mail delivery agent) written in C connects to the pg database to do some queries everytime a new mail comes in. I didn't find a solution for connection pooling yet. About the TODO items, apache has a nice description of their accept() serialization: http://httpd.apache.org/docs-2.0/misc/perf-tuning.html Perhaps this could be useful if someone decided to start implementing those features. Regards, Michael Paesold ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
