X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id EB0B49DC88B for ; Thu, 23 Feb 2006 06:21:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 12121-10 for ; Thu, 23 Feb 2006 06:21:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by postgresql.org (Postfix) with ESMTP id 2E4959DC833 for ; Thu, 23 Feb 2006 06:21:39 -0400 (AST) Received: from [84.143.19.230] (helo=pse.dyndns.org) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FCDbK2d32-0007mt; Thu, 23 Feb 2006 11:21:38 +0100 Received: from pse1 ([192.168.0.3]) by pse.dyndns.org with esmtp (Exim 4.44) id 1FCDbI-0001YX-2H; Thu, 23 Feb 2006 11:21:32 +0100 Message-ID: <43FD8CA6.10802@pse-consulting.de> Date: Thu, 23 Feb 2006 10:21:26 +0000 From: Andreas Pflug User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Kings-Lynne CC: ryan groth , Stephan Szabo , "Steinar H. Gunderson" , pgsql-performance@postgresql.org Subject: Re: Joins and full index scans...mysql vs postgres? References: <43FD235B.7000207@familyhealth.com.au> In-Reply-To: <43FD235B.7000207@familyhealth.com.au> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:0ce7ee5c3478b8d72edd8e05ccd40b70 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.081 required=5 tests=[AWL=0.081] X-Spam-Score: 0.081 X-Spam-Level: X-Archive-Number: 200602/361 X-Sequence-Number: 17347 Christopher Kings-Lynne wrote: > The pgAdmin query tool is known to give an answer about 5x the real > answer - don't believe it! Everybody please forget immediately the factor 5. It's no factor at all, but the GUI update time that is *added*, which depends on rows*columns. > ryan groth wrote: > >> the pgadmin query tool saying that the query runs >> "997+3522 ms". Means 997ms until all data is at the client (libpq reports the rowset), the rest is GUI overhead. Regards, Andreas