Re: Connection pooling - Number of connections

Reaching the maxPoolSize from the minPoolSize means creating the
connections at the crucial moment where the client application is in the
desperate need of completing an important query/transaction which the
primary responsibility since it cannot hold the data collected.

So here the connection creation action is the costliest among all the other
management tasks. so keeping the connections ready is the best option.

poolSize parameter is very good in the sense when the application owner
know what is the optimal number to put, after having application
performance analysed with the history of previous settings and the
improvements made on it. server sizing always shows up in this sort of
analysis.

On Fri, Mar 21, 2014 at 9:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> writes:
> > On Fri, Mar 21, 2014 at 4:49 PM, David Johnston <polobo(at)yahoo(dot)com>
> wrote:
> >> Consider this train-of-thought: no matter how large the pool size if
> you
> >> are constantly keeping, say, 90% of the connections actively working
> then
> >> having, on average, 10% of the connections sitting idle is probably not
> >> going to be noticeable on the server and the reduction in overhead of
> >> managing a pool is typically a net positive. Now, I had no clue what
> >> percentage is actually true, or under what conditions and pool sizes it
> may
> >> vary, but that is a calculation that someone deciding on between
> managed and
> >> un-managed pools would need to make.
>
> > Sure.
>
> > The big question is if it is suited for general purpose or if having
> > 100 connections open when 10 only are necessary at the time is causing
> > any unnecessary contention/spinlock issues/performance
> > overhead/whatever...
>
> It will cost you, in ProcArray scans for example. But lots-of-idle-
> connections is exactly what a pooler is supposed to prevent. If you have
> a server that can handle say 10 active queries, you should have a pool
> size of 10, not 100. (If you have a server that can actually handle
> 100 active queries, I'd like to have your IT budget.)
>
> The proposed design sounds fairly reasonable to me, as long as users are
> clear on how to set the pool size --- and in particular that bigger is
> not better. Clueless users could definitely shoot themselves in the
> foot, though.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>