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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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