Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id E9E4F63282E for ; Thu, 9 Sep 2010 15:07:43 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 66235-08 for ; Thu, 9 Sep 2010 18:07:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id 457846323A3 for ; Thu, 9 Sep 2010 15:07:36 -0300 (ADT) Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0McyCA-1PByrx2xE2-00HmDm; Thu, 09 Sep 2010 20:07:24 +0200 Message-ID: <4C89225A.1080504@2ndquadrant.com> Date: Thu, 09 Sep 2010 14:07:22 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Kevin Grittner CC: David Kerr , pgsql-performance@postgresql.org, Tom Lane Subject: Re: pgbench could not send data to client: Broken pipe References: <20100908174629.GD40339@mr-paradox.net> <8037.1283973026@sss.pgh.pa.us> <4C87E3A6.8060800@2ndquadrant.com> <20100908195654.GB49941@mr-paradox.net> <9771.1283978128@sss.pgh.pa.us> <20100908204443.GG49941@mr-paradox.net> <4C87B22802000025000353B7@gw.wicourts.gov> <20100908212056.GI49941@mr-paradox.net> <4C87BF0502000025000353BE@gw.wicourts.gov> <20100908220011.GA59539@mr-paradox.net> <4C87C77C02000025000353D2@gw.wicourts.gov> <4C8905C5.1060709@2ndquadrant.com> <4C88D1F1020000250003544F@gw.wicourts.gov> In-Reply-To: <4C88D1F1020000250003544F@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:0Th6sGdc5kz1nC4BiIcFcHfXmi10LhcKkmYIPnQLZhq 1nqJFHbt+f10K+M1ZDqPha1iQZW79TQFarGv8cMN/RIUCPqEJe lEFw2r4lLaHy3bOkbOON8ugnWOehhQk24EtnfaVDBdiZbzEkha X5RgMLaYsSset3Nphn2E4ZdbMQ1hYRpLnrNcTKm1tJa1WtU1nD Z82BOylSZ7Jaxhb583kVGzlakpFUZusfN4/y/pGdiM= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201009/46 X-Sequence-Number: 40249 Kevin Grittner wrote: > In my experience you can expect the response time benefit of > reducing the size of your connection pool to match available > resources to be more noticeable than the throughput improvements. > This directly contradicts many people's intuition, revealing the > downside of "gut feel". > This is why I focused on showing there won't actually be a significant throughput reduction, because that part is the most counterintuitive I think. Accurately modeling the latency improvements of pooling requires much harder math, and it depends quite a bit on whether incoming traffic is even or in bursts. Easier in many cases to just swallow expectations and estimates and just try it instead. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us