Re: Connection pooling - Number of connections

On Tue, Mar 25, 2014 at 5:24 AM, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz
> wrote:

> Surely no code changes are required, as one can simply set the min and
> max pool sizes to be the same?
>
> Cheers,
> Gavin
>

To be sure it can be implemented that way, but its a question of design
targets. For example, if a pool is allowed to grow and shrink, the design
might encompass a pool of threads that try to maintain the
configured-minimum idle connections to respond to spike demands. And there
is the additional setting in the pool for users to [typically] misconfigure.

However, if the pool is fixed size, and attrition from the pool is only by
idle timeout (typically measured in minutes), the design does not need to
account for spike demand. Likely connections that have dropped out can
either be restored on-demand rather than something running constantly in
the background trying to maintain and idle level.

One of the attributes of HikariCP is a minimalistic set of configuration
options with sane defaults, and minimalistic code. There are many
competitor pools, offering dozens of settings ranging form banal to unsafe.
HikariCP initially even offered some of these options, but one-ny-one
they're getting the ax. More and more we're trying to look at what is the
true core functionality that user's need -- eliminate what is unnecessary
and easily misconfigured.

Thus a debate started over in our group, with some similar views as
expressed here (on both sides). Guillaume Smet was concerned about the
impact of idle connections on active ones in PostgreSQL (in a fixed pool
scenario) and wanted to ask some of the experts over here.