From: | Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Cc: | Brett Wooldridge <brett(dot)wooldridge(at)gmail(dot)com> |
Subject: | Connection pooling - Number of connections |
Date: | 2014-03-21 14:49:16 |
Message-ID: | CALt0+o-5wuUA_1TjNTb+xP43=Ua6ge5PuyOo51QcmDM6cnm9-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi all,
Brett Wooldridge, the creator of HikariCP [1] - a high performance
Java connection pool - is contemplating the idea to change the way
pooling is done in HikariCP and have a fixed-size pool of connections
always open.
No maxPoolSize, no minIdle, no minPoolSize, juste a poolSize parameter
which sets the size of the pool. At application startup, all the
connections are opened and maintained by the pool throughout the life
of the application.
The basic idea is that if you decide that your application might need
100 connections at time, you set poolSize to 100 and HikariCP
maintains 100 connections open.
I recall very old posts on this list where people were talking about
code paths sensitive to the number of connections open (or even
max_connections) and that it wasn't such a good idea to keep
connections open if they were not really needed.
As a lot of scalability work has been done since this (very old) time,
I was wondering if it was still the rule of thumb or if the idea of
Brett to completely simplify the connection management is the way to
go.
It seems that at least another pool implementation is going this way
so I thought it might be a good idea to have the opinion of the
database side of things. This way, it will be easier to take a well
informed decision.
Thanks in advance for your comments/advices.
--
Guillaume
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2014-03-21 15:49:43 | Re: Connection pooling - Number of connections |
Previous Message | Tom Lane | 2014-03-21 14:06:51 | Re: Getting query plan alternatives from query planner? |