Re: Connection pooling - Number of connections

Sure. It's all just code. It's not particularly a question of efficiency,
I'm sure it could be made equally efficient. But "simpler" code-wise would
be not having two implementations, or not having one that is designed to
try to keep up with spike demands. The question for this group was really
around PostgreSQL performance regarding the impact of idle connections. If
there is a pool of 20 connections, and half of them are idle, what is the
impact performance-wise of the idle connections on the active connections?

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

> 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> 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.
>
>