Re: Pooling in Core WAS: Need help in performance tuning. - Mailing list pgsql-performance

From Robert Haas
Subject Re: Pooling in Core WAS: Need help in performance tuning.
Date
Msg-id AANLkTinQugGNosQSyFmtj8jA=u-zq7pOx0JVFb5oW0=9@mail.gmail.com
Whole thread Raw
In response to Re: Pooling in Core WAS: Need help in performance tuning.  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Pooling in Core WAS: Need help in performance tuning.
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Next
From: Tom Lane
Date:
Subject: Re: Pooling in Core WAS: Need help in performance tuning.