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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
