Re: Connection pooling - Number of connections - Mailing list pgsql-performance

From Brett Wooldridge
Subject Re: Connection pooling - Number of connections
Date
Msg-id CAPg6oRPEPza2_wvCj1gNfD4ac=7eO4bak6nVZrfKbD0Mk=zrJw@mail.gmail.com
Whole thread Raw
In response to Re: Connection pooling - Number of connections  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-performance
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@archidevsys.co.nz> wrote:
On 25/03/14 13:23, Brett Wooldridge wrote:
On Tue, Mar 25, 2014 at 5:24 AM, Gavin Flower <GavinFlower@archidevsys.co.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.


pgsql-performance by date:

Previous
From: Gavin Flower
Date:
Subject: Re: Connection pooling - Number of connections
Next
From: gianfranco caca
Date:
Subject: pg_dump vs pg_basebackup