Message-ID: <4EC21D24.3060804@gmx.at>
Date: Tue, 15 Nov 2011 09:04:52 +0100
From: Mario Weilguni <roadrunner6@gmx.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Large number of short lived connections - could a connection
	pool help?
References: 
 <CAPVp=gYKyQxy2D_3npH0WB313DPTGVao+BifXKKq_Mc7jA07bg@mail.gmail.com>
In-Reply-To: 
 <CAPVp=gYKyQxy2D_3npH0WB313DPTGVao+BifXKKq_Mc7jA07bg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 15.11.2011 01:42, schrieb Cody Caughlan:
> We have anywhere from 60-80 background worker processes connecting to
> Postgres, performing a short task and then disconnecting. The lifetime
> of these tasks averages 1-3 seconds.
>
> I know that there is some connection overhead to Postgres, but I dont
> know what would be the best way to measure this overheard and/or to
> determine if its currently an issue at all.
>
> If there is a substantial overheard I would think that employing a
> connection pool like pgbouncer to keep a static list of these
> connections and then dole them out to the transient workers on demand.
>
> So the overall cumulative number of connections wouldnt change, I
> would just attempt to alleviate the setup/teardown of them so quickly.
>
> Is this something that I should look into or is it not much of an
> issue? Whats the best way to determine if I could benefit from using a
> connection pool?
>
> Thanks.
>
I had a case where a pooler (in this case pgpool) resulted in a 140% 
application improvement - so - yes, it is probably a win to use a 
pooling solution.