Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id D9046632954 for ; Sun, 1 Mar 2009 13:32:57 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 90576-10 for ; Sun, 1 Mar 2009 13:32:55 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from linos.es (centrodatos.linos.es [86.109.105.97]) by mail.postgresql.org (Postfix) with ESMTP id A27DC6325CE for ; Sun, 1 Mar 2009 13:32:31 -0400 (AST) Received: (qmail 20523 invoked from network); 1 Mar 2009 18:12:32 +0100 Received: from 230.87.220.87.dynamic.jazztel.es (HELO ?192.168.1.4?) (info@linos.es@87.220.87.230) by linos.es with SMTP; 1 Mar 2009 18:12:32 +0100 Message-ID: <49AAC6AC.60309@linos.es> Date: Sun, 01 Mar 2009 18:32:28 +0100 From: Linos User-Agent: Thunderbird 2.0.0.19 (X11/20090213) MIME-Version: 1.0 To: "Ross J. Reedstrom" , pgsql-performance@postgresql.org Subject: Re: TCP network cost References: <1ca1c1410902171013q478f2620n13fcd68cb8b3d911@mail.gmail.com> <20090217070403.GB2486@cooker> <3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com> <20090217070403.GB2486@cooker> <3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com> <20090217200416.GA23707@cooker> <87hc2r272g.fsf@oxford.xeocode.com> <20090223194212.GA14802@cooker> <27042.1235423820@sss.pgh.pa.us> <20090224170201.GA25420@cooker> In-Reply-To: <20090224170201.GA25420@cooker> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/2 X-Sequence-Number: 32924 Ross J. Reedstrom escribió: > Excellent. I'll take a look at this and report back here. > > Ross > > > On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote: >> "Ross J. Reedstrom" writes: >>> Summary: C client and large-object API python both send bits in >>> reasonable time, but I suspect there's still room for improvement in >>> libpq over TCP: I'm suspicious of the 6x difference. Detailed analysis >>> will probably find it's all down to memory allocation and extra copying >>> of bits around (client side) >> I wonder if the backend isn't contributing to the problem too. It chops >> its sends up into 8K units, which doesn't seem to create huge overhead >> in my environment but maybe it does in yours. It'd be interesting to see >> what results you get from the attached quick-and-dirty patch (against >> HEAD, but it should apply back to at least 8.1). >> >> regards, tom lane > Hello, i have been having a problem like this in debian machines and i have discovered that (almost in my case), the problem only arises when i am using "ssl = true" in postgresql.conf although i am using clear tcp connections to localhost to perform my query, if i disable ssl in configuration my localhost query times goes from 4200ms to 110ms, the same parameter does not have this effect in my Arch Linux development machine, so maybe you should see how this parameter affect your setup Ross. My original post to general list is in http://archives.postgresql.org/pgsql-general/2009-02/msg01297.php for more information. Regards, Miguel Angel.