From: Gavin Flower <GavinFlower@archidevsys.co.nz>
To: Brett Wooldridge <brett.wooldridge@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Connection pooling - Number of connections
Date: Tue, 25 Mar 2014 14:42:32 +1300
Message-ID: <5330DF08.6020005@archidevsys.co.nz> (raw)
In-Reply-To: <CAPg6oRM+0fLGiX-3yGZ3_vU=fKrfs7Ahr=9oO0n0zRDCugu0eA@mail.gmail.com>
References: <CAPg6oRMd6YzgKv9ZBdK806Rux4EjJ4u046F1j=96NWU+urmYEw@mail.gmail.com>
<53309465.2000204@archidevsys.co.nz>
<CAPg6oRM+0fLGiX-3yGZ3_vU=fKrfs7Ahr=9oO0n0zRDCugu0eA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 25/03/14 13:23, Brett Wooldridge wrote:
> On Tue, Mar 25, 2014 at 5:24 AM, Gavin Flower
> <GavinFlower@archidevsys.co.nz <mailto: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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: GavinFlower@archidevsys.co.nz, brett.wooldridge@gmail.com
Subject: Re: Connection pooling - Number of connections
In-Reply-To: <5330DF08.6020005@archidevsys.co.nz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox