Re: performance config help - Mailing list pgsql-performance

From Craig Ringer
Subject Re: performance config help
Date
Msg-id 4B4EAF61.1030501@postnewspapers.com.au
Whole thread Raw
In response to Re: performance config help  (Bob Dusek <redusek@gmail.com>)
List pgsql-performance
Bob Dusek wrote:

> So, pgBouncer is pretty good.  It doesn't appear to be as good as
> limiting TCON and using pconnect, but since we can't limit TCON in a
> production environment, we may not have a choice.

It may be worth looking into pgpool, as well. If you have a very
cheap-to-connect-to local pool you can use non-persistent connections
(for quick release) and the local pool takes care of maintaining and
sharing out the expensive-to-establish real connections to Pg its self.

If you find you still can't get the throughput you need, an alternative
to adding more hardware capacity and/or more server tuning is to look
into using memcached to satisfy many of the read requests for your app
server. Use some of that 16GB of RAM on the app server to populate a
memcached instance with less-frequently-changing data, and prefer to
fetch things from memcached rather than from Pg. With a bit of work on
data access indirection and on invalidating things in memcached when
they're changed in Pg, you can get truly insane boosts to performance
... and get more real work done in Pg by getting rid of repetitive
queries of relatively constant data.

--
Craig Ringer

pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: a heavy duty operation on an "unused" table kills my server
Next
From: Craig Ringer
Date:
Subject: Re: performance config help