Skip site navigation (1) Skip section navigation (2)

Re: Pre-forking backend

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Ken Hirsch <kenhirsch(at)myself(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pre-forking backend
Date: 2001-09-30 01:54:44
Message-ID: 3.0.5.32.20010930095444.015ed1c0@192.228.128.13 (view raw or flat)
Thread:
Lists: pgsql-hackers
At 04:50 PM 9/29/01 -0400, Tom Lane wrote:
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.


In response to

pgsql-hackers by date

Next:From: sean-pgsql-hackersDate: 2001-09-30 02:28:01
Subject: Re: Pre-forking backend
Previous:From: Peter EisentrautDate: 2001-09-29 22:55:24
Subject: Re: doc build error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group