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

From Bradley McLean
Subject Re: Pre-forking backend
Date
Msg-id 20010930115653.B16547@bradm.net
Whole thread Raw
In response to Re: Pre-forking backend  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: Pre-forking backend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Gavin Sherry (swm@linuxworld.com.au) [010930 06:13]:
> On Sat, 29 Sep 2001 sean-pgsql-hackers@chittenden.org wrote:
> 
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > How hard would it be to pre-fork an extra backend
> > > 
> > > How are you going to pass the connection socket to an already-forked
> > > child process?  AFAIK there's no remotely portable way ...
> > 
> > Umm... Apache?  They use a preforking model and it works quite well for 
> > every *NIX that Apache runs on.  ;)  Maybe RSE can comment on this 
> > further... -sc
> 
> It works very good for what Apache requires. Namely, to have a queue of
> processes ready to serve pages. Its not that simple with PostgreSQL - as
> the discussion so far has drawn out - since there is no simple way to
> guarantee that the 'right' child gets the socket. The reason why there
> needs to be a 'right' child is that a socket needs to be passed to a child
> which has started up for a given database. Otherwise, there's no benefit.

Interesting:  So as the number of databases served by a given system
approaches one, the efficiency of this increases.

Is it useful if it only works for one database within a server?  I can
envision applications for this.

-Brad


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PL/pgSQL bug?
Next
From: Peter Eisentraut
Date:
Subject: Re: CVS changes