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
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 |