> I would stick to proven postgresql technologies such as pgbouncer.

Thanks for the fast recommendation, Joshua. I'll consider it.

Our application is Slony-replicated web/db project with two slaves.

Does this design seem sensible?

- Run one pgbouncer server on the master, with settings to
service the master and both slaves.

- We already handle balancing traffic between the slaves separately, so
that can remain unchanged.

- Use Session Pooling both both the masters and the slaves. In theory,
the slaves should just be doing transaction-less SELECT statements, so a
more aggressive setting might be possible, but I believe there might be
a "leak" in the logic where we create a temporary table on the slave in
one case.

- Redirect all application connections through pgbouncer

###

From graphs we keep, we can see that the slaves currently use a max of
about 64 connections...they are far from maxing out what's possible. So
I was trying to think through if made sense to bother using the
pgBouncer layer with them. I through of two potential reasons to still
use it:
- In the event of a major traffic spike on the web servers, pgbouncer
would keep the number of db slots under control.
- Potentially there's a performance gain in having PgBouncer hold the
connections open.

Does that analysis seem correct?

For the master's pool size, I thought I would just choose a number
that's a little larger that the daily max number of DB slots in use.

Mark


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance