From: | Bradley McLean <brad(at)bradm(dot)net> |
---|---|
To: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pre-forking backend |
Date: | 2001-09-30 15:56:53 |
Message-ID: | 20010930115653.B16547@bradm.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Gavin Sherry (swm(at)linuxworld(dot)com(dot)au) [010930 06:13]:
> On Sat, 29 Sep 2001 sean-pgsql-hackers(at)chittenden(dot)org wrote:
>
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-09-30 16:03:33 | Re: CVS changes |
Previous Message | Marko Kreen | 2001-09-30 15:40:20 | Re: Glitch in handling of postmaster -o options |