On 7/27/10 6:56 PM, Tom Lane wrote:
> Yeah, if it weren't for that I'd say "sure let's try it". But I'm
> afraid we'd be introducing significant headaches in return for a gain
> that's quite speculative.
Well, the *gain* isn't speculative. For example, I am once again
dealing with the issue that PG backend processes on Solaris never give
up their RAM, resulting in pathological swapping situations if you have
many idle connections. This requires me to install pgpool, which is
overkill (since it has load balancing, replication, and more) just to
make sure that connections get recycled so that I don't have 300 idle
connections eating up 8GB of RAM.
Relative to switching databases, I'd tend to say that, like pgbouncer
and pgpool, we don't need to support that. Each user/database combo can
have their own "pool". While not ideal, this would be good enough for
90% of users.
-- Josh Berkus
PostgreSQL Experts Inc.
In response to
pgsql-performance by date
|Next:||From: Robert Haas||Date: 2010-07-28 19:52:19|
|Subject: Re: Pooling in Core WAS: Need help in performance tuning.|
|Previous:||From: Yeb Havinga||Date: 2010-07-28 15:18:27|
|Subject: Re: Testing Sandforce SSD|