Re: Connection pooling - Number of connections

From: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Johnston <polobo(at)yahoo(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Connection pooling - Number of connections
Date: 2014-03-21 18:36:10
Message-ID: CALt0+o8BffN73JzsEQRas1zhbRXCq=EmnMoEH9OcDqsAYEHfNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi Tom,

On Fri, Mar 21, 2014 at 5:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Yeah, well.

My understanding of what happened on the field is that people usually
set the pool size limit quite high because they don't want to
experience connection starvation even if there is a temporary slowdown
of their application/database.

Is the overhead of having 100 connections open noticeable or is it
better to not have them but not so bad to have them?

Thanks.

--
Guillaume

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Guillaume Smet 2014-03-21 18:38:56 Re: Connection pooling - Number of connections
Previous Message Sethu Prasad 2014-03-21 17:51:57 Re: Connection pooling - Number of connections