On Mon, 28 Jan 2002, Chris Ruprecht wrote:
> Ok, so from what I see on here, pg_pconnect doesn't have any
> advantages over pg_connect in my situation. I have the web server
> running on the same machine as the database server and yes, I have
> allocated 16384 shared buffers (at 8 KB each, this is 128 MB of
> shared memory). I have not noticed any connect overhead when opening
> a web page which connects to the database (99% of them do), the
> connection is instantaneously, so I guess, I don't need to do
> anything here.
> I was under the impression, that a persistent connection would open
> one and only one process which then will be used all the time without
> creating more child processes which keep lingering about. I guess, I
> was wrong here ...
You're right: one process *per httpd child*. You do want lingering
processes, it's all what pconnect is about. Persistent connections
means persistent postgres backends, of course.
On a server with usually 50/100 httpd processes (and a good request/sec
ratio), it makes a difference if every httpd process is paired with a
postgres backend. No connect(), no fork()/exec(), no auth overhead.
Just read()/write() on preexisting socket.
>
> Best regards,
> Chris
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it