Re: Connection pooling - Number of connections

От: Gavin Flower
Тема: Re: Connection pooling - Number of connections
Дата: ,
Msg-id: 5330DF08.6020005@archidevsys.co.nz
(см: обсуждение, исходный текст)
Ответ на: Re: Connection pooling - Number of connections  (Brett Wooldridge)
Ответы: Re: Connection pooling - Number of connections  (Brett Wooldridge)
Список: pgsql-performance

Скрыть дерево обсуждения

Connection pooling - Number of connections  (Brett Wooldridge, )
 Re: Connection pooling - Number of connections  (Gavin Flower, )
  Re: Connection pooling - Number of connections  (Brett Wooldridge, )
   Re: Connection pooling - Number of connections  (Gavin Flower, )
    Re: Connection pooling - Number of connections  (Brett Wooldridge, )
 Re: Connection pooling - Number of connections  (Josh Berkus, )
  Re: Connection pooling - Number of connections  (Brett Wooldridge, )
 Re: Connection pooling - Number of connections  (Jeff Janes, )

On 25/03/14 13:23, Brett Wooldridge wrote:
On Tue, Mar 25, 2014 at 5:24 AM, Gavin Flower <> 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 по дате сообщения:

От: David Johnston
Дата:
Сообщение: Re: pg_dump vs pg_basebackup
От: Claudio Freire
Дата:
Сообщение: Re: pg_dump vs pg_basebackup