Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 93BEB1C2F15 for ; Thu, 3 May 2012 12:28:52 -0300 (ADT) Received: from mail.amadorgroup.biz ([64.42.211.250] helo=amadorgroup.biz) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxxZ-0006V2-An for pgsql-performance@postgresql.org; Thu, 03 May 2012 15:28:51 +0000 X-MDAV-Processed: amadorgroup.biz, Thu, 03 May 2012 09:28:31 -0600 Received: from [172.17.2.104] by amadorgroup.biz (MDaemon PRO v12.5.4) with ESMTP id md50003199144.msg for ; Thu, 03 May 2012 09:28:30 -0600 X-Spam-Processed: amadorgroup.biz, Thu, 03 May 2012 09:28:30 -0600 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: rhahn@docfocus.ca X-MDRemoteIP: 172.17.2.104 X-Return-Path: rhahn@docfocus.ca X-Envelope-From: rhahn@docfocus.ca X-MDaemon-Deliver-To: pgsql-performance@postgresql.org Message-ID: <4FA2A42C.9090900@docfocus.ca> Date: Thu, 03 May 2012 09:28:44 -0600 From: "Ronald Hahn, DOCFOCUS INC." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Result Set over Network Question References: <4F9EDACA.4010901@docfocus.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090007030107090700000208" X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/33 X-Sequence-Number: 46857 This is a multi-part message in MIME format. --------------090007030107090700000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit After some testing using wiershark (poor mans profiler) to see what was going on with the network I found that it was the tools I've been using. Both Aqua and PGadminIII have a large overhead per column to get the meta data. MSSQL sends that data upfront so the impact isn't as bad. I'm not sure if it's a limitation of the pgsql protocol vs tds or a limitation of Aqua or a combination of both. At any rate it turns out not to be part of the problem I'm having with my software stalling out so I'm back to Square one with my problem. Thanks, Ron --------------090007030107090700000208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After some testing using wiershark (poor mans profiler) to see what was going on with the network I found that it was the tools I've been using. Both Aqua and PGadminIII have a large overhead per column to get the meta data. MSSQL sends that data upfront so the impact isn't as bad. I'm not sure if it's a limitation of the pgsql protocol vs tds or a limitation of Aqua or a combination of both. At any rate it turns out not to be part of the problem I'm having with my software stalling out so I'm back to Square one with my problem.

Thanks,
Ron

--------------090007030107090700000208--