On Tue, Apr 6, 2010 at 1:09 PM, David Kerr <dmk@mr-paradox.net> wrote:
> On Mon, Apr 05, 2010 at 10:44:53PM -0400, Merlin Moncure wrote:
> - pgbouncer is totally transparent. I manage quite a few databases and
> - I use it (w/session mode) so I can psql to a single host (localhost),
> - and bounce between different databases. Like I said earlier, you have
> - discreet pools based on role -- otherwise there would be no really
> - good way to control the role your queries would operate under. This
> - will keep your etl from drilling your box, and if you keep your
> - pool_size under the number of cores you have, you will have some
> - available if things get really dicey, which is nice.
>
> right, so that's kind of my issue, the ETL process will log in as 1 user, and connect to 1 database
> wouldn't that mean that if i set max_pool_size = 30 then i'd have at max 30 connections allowed to
> the DB from that user?
yes. pool_size connections per role per db. unless you hardcode role
in the bouncer->backend connection string then it's just per db, and
the libpq->bouncer role is only used to auth to bouncer than ignored
iirc.
bouncer uses libevent, so with epoll on linux can give you excellent
performance. that also makes it single threaded, which is extremely
nice. it's pretty hard to max out a bouncer cpu core before the
database bottlenecks you, but on your hardware things might be
different.
merlin