From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | lindner(at)inuus(dot)com, Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Prepared Statements vs. pgbouncer |
Date: | 2007-10-01 18:18:54 |
Message-ID: | 47013A0E.6080607@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Heikki,
> You might also consider if using pgbouncer or similar really is
> necessary. Perhaps you could get away with a per-client connection pool,
> with "min pool size" small enough, maybe 0, that the number of
> simultaneous connections to the server would stay reasonable.
>
It becomes necessary whenever you have a large number of appservers
connecting to the same database server. Setting min pool size downwards
isn't really effective becuase then you're just adding connection time
delays ... exactly what you're trying to prevent by using a connection pool.
I'm working on a scalable project myself which is why I'm concerned
about this. The reason why we're planning to rely on pgBouncer is that
we'll have both java and non-java applications connecting to the same
database, and we don't want to manage two different connection/failover
pools. So it's important to us that PG-JDBC function with independant
connection pools.
So where is it going to be easier to fix this ... pgBouncer, or pg-JDBC?
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2007-10-01 18:35:59 | Re: Prepared Statements vs. pgbouncer |
Previous Message | Till Toenges | 2007-10-01 16:52:50 | Re: Prepared Statements vs. pgbouncer |