Re: Pre-forking backend
От | Bradley McLean |
---|---|
Тема | Re: Pre-forking backend |
Дата | |
Msg-id | 20010930115653.B16547@bradm.net обсуждение исходный текст |
Ответ на | Re: Pre-forking backend (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: Pre-forking backend
|
Список | 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 по дате отправления: