Re: Prepared Statements vs. pgbouncer
От | Josh Berkus |
---|---|
Тема | Re: Prepared Statements vs. pgbouncer |
Дата | |
Msg-id | 47013A0E.6080607@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Prepared Statements vs. pgbouncer (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Prepared Statements vs. pgbouncer
Re: Prepared Statements vs. pgbouncer |
Список | 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
В списке pgsql-jdbc по дате отправления: