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  (Dave Cramer <pg@fastcrypt.com>)
Re: Prepared Statements vs. pgbouncer  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Till Toenges
Дата:
Сообщение: Re: Prepared Statements vs. pgbouncer
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Prepared Statements vs. pgbouncer