On Tue, Apr 6, 2010 at 1:09 PM, David Kerr <dmk@xxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
