Indeed, here is an excerpt from my original post with the context intact:
-> I haven't found PG to have much connection overhead, why would
open/closing
-> a connection-per-query require server side connection pooling? You might
-> try having your application acquire a connection on-demand and then
having a
-> timeout mechanism that discards the connection after a certain amount of
-> idle time. That [way] if you have to fire off hundreds of small queries
you don't
-> encounter connection overhead. If the machine is idle, it disconnects
and
-> the server doesn't get loaded down with tons of idle backends.
This *would* be my definition of sensible caching. It is the best of both
worlds, superceded only by an intelligent middle tier.
jc
-----Original Message-----
From: Joseph Shraibman [mailto:jks@selectacast.net]
Sent: Tuesday, December 19, 2000 5:30 PM
To: Clark, Joel
Subject: Re: [INTERFACES] Connection Pooling...(Repost)...please do
help..
With sensible caching you won't have too many more open than you need.
"Clark, Joel" wrote:
>
> Yes, but the load of 200 concurrent fork()ed backends might be worse. :)
>
> jc
>
> -----Original Message-----
> From: Joseph Shraibman [mailto:jks@selectacast.net]
> Subject: Re: [INTERFACES] Connection Pooling...(Repost)...please do
> help..
>
> "Clark, Joel" wrote:
> >
> > I haven't found PG to have much connection overhead, why would
> open/closing
> > a connection-per-query require server side connection pooling?
>
> Each connection causes the backend to fork. With a heavy load you'll
> feel the overhead of creating and closing so many connections.
>
> --
> Joseph Shraibman
> jks@selectacast.net
> Increase signal to noise ratio. http://www.targabot.com
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com