Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 2FBBA6328AF for ; Sun, 1 Mar 2009 14:20:33 -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 41592-10 for ; Sun, 1 Mar 2009 14:20:13 -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 56709632796 for ; Sun, 1 Mar 2009 14:20:04 -0400 (AST) Received: (qmail 29800 invoked from network); 1 Mar 2009 19:00:04 +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 19:00:04 +0100 Message-ID: <49AAD1CF.6000908@linos.es> Date: Sun, 01 Mar 2009 19:19:59 +0100 From: Linos User-Agent: Thunderbird 2.0.0.19 (X11/20090213) MIME-Version: 1.0 To: Tom Lane , "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> <49AAC6AC.60309@linos.es> <13121.1235929398@sss.pgh.pa.us> <49AACC6F.7080809@linos.es> <13505.1235931000@sss.pgh.pa.us> In-Reply-To: <13505.1235931000@sss.pgh.pa.us> 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/6 X-Sequence-Number: 32928 Tom Lane escribió: > Linos writes: >> Tom Lane escribió: >>> Does that number include connection startup overhead? (If it doesn't, >>> it'd be pretty strange.) > >> This difference it is from the runtime of the query, i get this with \timing >> parameter in psql, > > That's just weird --- ssl off should be ssl off no matter which knob you > use to turn it off. Are you sure it's really off in the slow connections? > > regards, tom lane Maybe i am missing something, i use the same command to connect to it from localhost "psql -d database -h localhost" and in the pcap files i have captured the protocol it is clear (with "ssl = false" or "ssl = true" either), but in the debian machine with "ssl = true" in postgresql.conf you can see in the pcap file big time jumps between data packets, psql commandline enables automatically ssl if the server supports it? but if this is the case i should see encrypted traffic in pcap files, and the problem should be the same in Arch Linux, no? If you want that i make a local test explain me the steps and i will try here. Regards, Miguel Angel.