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

Browse pgsql-hackers by date

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