| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Pooling in Core WAS: Need help in performance tuning. |
| Date: | 2010-07-28 19:44:49 |
| Message-ID: | 4C5088B1.70902@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-07-28 19:52:19 | Re: Pooling in Core WAS: Need help in performance tuning. |
| Previous Message | Yeb Havinga | 2010-07-28 15:18:27 | Re: Testing Sandforce SSD |