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

Re: Pre-forking backend

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: "Steve Wolfe" <steve(at)iboats(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pre-forking backend
Date: 2001-10-01 03:27:25
Message-ID: 3.0.5.32.20011001112725.012e97d0@192.228.128.13 (view raw or flat)
Thread:
Lists: pgsql-hackers
At 08:16 PM 30-09-2001 -0600, Steve Wolfe wrote:
>> >
>> > How hard would it be to pre-fork an extra backend for the database a
>> > user just requested so if they next user asks for the same database, the
>> > backend would already be started?
>
>  Perhaps I'm missing something, but it seems to me that the cost of forking
>a new backend would be pretty trivial compared to the expense of processing
>anything but the most simple query.  Am I wrong in that?

I think forking costs a lot on Solaris. That's why Sun promotes threads :).

I still don't see many advantages of doing the preforking in postgresql.
What would the benefits be? Able to open and close db connections many
times a second? Any other advantages?

Can't the apps do their own preforking? All they do is preopen their own db
connections. Then they can take care of whatever initialization and details
they want.

It seems that opening and closing db connections over the network will
always be slower than just leaving a prepared connection open, looking at
just the network connection setup time alone.

I suppose it is helpful for plain cgi scripts, but those don't scale do they?

Cheerio,
Link.


In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-10-01 04:15:12
Subject: Problem on AIX with current
Previous:From: Bruce MomjianDate: 2001-10-01 02:50:17
Subject: Re: Pre-forking backend

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