Skip site navigation (1) Skip section navigation (2)

Re: Pooling in Core WAS: Need help in performance tuning.

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 (view raw or flat)
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

In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2010-07-28 19:52:19
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Previous:From: Yeb HavingaDate: 2010-07-28 15:18:27
Subject: Re: Testing Sandforce SSD

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group