In response to Kirk Strauser <kirk@strauser.com>:
> On Jan 15, 2009, at 12:30 PM, Steve Crawford wrote:
>
> > But if your application is designed to work well with pooling, it
> > can provide dramatic performance benefits.
>
> I think that's the problem. As I mentioned at one point, a lot of our
> applications have connections open for hours at a time and fire off
> queries when the user does something. I'm coming to think that
> pooling wouldn't give much benefit to long-living processes like that.
Actually, that's exactly the kind of app that should benefit from
pooling.
However, it pgpool can't pool connections if each connection has its
own username. Not sure what exactly is causing it not to work for you,
but that was the first thing that came to mind.
> On a related note, is max_connections=400 reasonably sized for a
> server with 8GB of RAM? Again, most of these are dormant at any given
> time. The database itself is currently hosted on a dual Xeon server
> with 3GB of RAM and other applications so I'm sure the new 8-core/8GB
> hardware is bound to do better at any rate.
It all depends. We had servers with 300 - 400 connections that did
just fine. We've looked at pgpool, but deemed it not worth the
added complexity. Quite honestly, why attempt to solve problems that
don't even exist?
Are you having a problem? If so, what is the problem?
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/