Re: Pooling in Core WAS: Need help in performance tuning.
От | Robert Haas |
---|---|
Тема | Re: Pooling in Core WAS: Need help in performance tuning. |
Дата | |
Msg-id | AANLkTinQugGNosQSyFmtj8jA=u-zq7pOx0JVFb5oW0=9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pooling in Core WAS: Need help in performance tuning. (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Pooling in Core WAS: Need help in performance tuning.
|
Список | pgsql-performance |
On Wed, Jul 28, 2010 at 3:44 PM, Josh Berkus <josh@agliodbs.com> wrote: > 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. However, if we don't support that, we can't do any sort of pooling-ish thing without the ability to pass file descriptors between processes; and Tom seems fairly convinced there's no portable way to do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-performance по дате отправления: