At 04:50 PM 9/29/01 -0400, Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> 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.
