On 25/03/14 13:23, Brett Wooldridge wrote:
> On Tue, Mar 25, 2014 at 5:24 AM, Gavin Flower
> <GavinFlower(at)archidevsys(dot)co(dot)nz <mailto: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.
>
Would it be a valid option to switch in simpler code when min = max and
both could be set to the same default? This would allow more efficient
code to be run for a fixed pool size and allow a sane default, while
preserving the option to have a range, though obviously not as simple as
only allowing a fixed pool size in terms of code complexity.