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.
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 |