Re: Pre-forking backend - Mailing list pgsql-hackers

From Lincoln Yeoh
Subject Re: Pre-forking backend
Date
Msg-id 3.0.5.32.20010930095444.015ed1c0@192.228.128.13
Whole thread Raw
In response to Re: Pre-forking backend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: doc build error
Next
From: Justin Clift
Date:
Subject: Re: Spinlock performance improvement proposal