DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	b=YqEehX3UwCKxgwYbQmz3fE3wh/RFhMRxIGQUXa/oe+B9QUGfxEuRzSWrWvkynrC1c4
	gcdlbJ2JOVOD4K4qt/n/RthzErob5d6VbuC3Mo4fMUiIm8v4kMO3oP7yKeDWTWB8zAMQ
	qRbhY15Tcs+cxAkTv9WaFjbmdZpaoaCd2GPLs=
Message-ID: <4C500E9F.5090304@gmail.com>
Date: Wed, 28 Jul 2010 14:03:59 +0300
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
References: <4C37A9C1.1060405@2ndquadrant.com>
	<4C37791C0200002500033379@gw.wicourts.gov>
	<4C37CBFB.1000800@agliodbs.com>
	<4C37EA1D.6000008@postnewspapers.com.au>
	<AANLkTimNJZlX7kFH_r0-BB_K3NGorU7BHd85SxXJbuGJ@mail.gmail.com>
	<4C38BF03.6060503@agliodbs.com> <19244.1278787866@sss.pgh.pa.us>
	<alpine.DEB.2.00.1007121044330.2534@aragorn.flymine.org>
	<4C3AF564.5030204@postnewspapers.com.au>
	<AANLkTikG_QqNXmGaAtnChGHyVAhdSosoE5M3MXwDKMH8@mail.gmail.com>
	<20100722212954.GA16758@anarazel.de>
	<AANLkTinnxNM2vOwB6-tkBhCQ=6+xChOfdjrofDEpxYxk@mail.gmail.com>
	<13654.1280263202@sss.pgh.pa.us>
	<AANLkTi=KtADzPgBSnfmPfk2YwoMaZ2=iq8BAtYbxjO8B@mail.gmail.com>
	<20776.1280282217@sss.pgh.pa.us>
In-Reply-To: <20776.1280282217@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

28.07.10 04:56, Tom Lane написав(ла):
>
> I'm not asserting it's true, just suggesting it's entirely possible.
> Other than the fork() cost itself and whatever authentication activity
> there might be, practically all the startup cost of a new backend can be
> seen as cache-populating activities.  You'd have to redo all of that,
> *plus* pay the costs of getting rid of the previous cache entries.
> Maybe the latter costs less than a fork(), or maybe not.  fork() is
> pretty cheap on modern Unixen.
>
>    
Actually as for me, the problem is that one can't raise number of 
database connections high without overloading CPU/memory/disk, so 
external pooling is needed. If postgresql had something like 
max_active_queries setting that limit number of connections that are not 
in IDLE [in transaction] state, one could raise max connections high 
(and I don't think idle process itself has much overhead) and limit 
max_active_queries to get maximum performance and won't use external 
pooling. Of course this won't help if the numbers are really high, but 
could work out the most common cases.

Best regards, Vitalii Tymchyshyn