At 04:50 PM 9/29/01 -0400, Tom Lane wrote: >Bruce Momjian <[EMAIL PROTECTED]> writes: >>> On some operating systems, only one child at a time can accept() on the >>> socket. On these, you have to lock around the call to accept(). > >> But how do you know the client wants the database you have forked? They >> could want a different one. > >This approach would only work as far as saving the fork() call itself, >not the backend setup time. Not sure it's worth the trouble. I doubt >that the fork itself is a huge component of our start time; it's setting >up all the catalog caches and so forth that's expensive.
I don't think there's much benefit as well. For most cases where preforking would help, you could just simply not disconnect. Get the app to connect to the correct DB on startup and then just wait, do stuff then don't disconnect either rollback or commit. Or have a DB connection pool. What would be good is a DB that can handle lots of connections well. That would help almost any case. Preforking is good for web servers but for DB servers it doesn't seem as useful. Cheerio, Link. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
