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 DCF899DC93E for ; Wed, 22 Feb 2006 19:39:08 -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 98383-10 for ; Wed, 22 Feb 2006 19:39:11 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from peufeu.com (unknown [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id 89A409DC832 for ; Wed, 22 Feb 2006 19:18:13 -0400 (AST) Received: (qmail 15440 invoked from network); 23 Feb 2006 00:19:00 +0100 Received: from unknown (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 23 Feb 2006 00:19:00 +0100 To: "ryan groth" , "Stephan Szabo" , "Steinar H. Gunderson" , pgsql-performance@postgresql.org Subject: Re: Joins and full index scans...mysql vs postgres? References: Message-ID: Date: Thu, 23 Feb 2006 00:18:58 +0100 From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.51 (Linux, build 1462) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.1 required=5 tests=[AWL=0.100] X-Spam-Score: 0.1 X-Spam-Level: X-Archive-Number: 200602/357 X-Sequence-Number: 17343 > "997+3522 ms". Am I reading these numbers wrong? Are these numbers > reflective of application performance? Is there an optimization I am > missing? It also reflects the time it takes to pgadmin to insert the results into its GUI... If you want to get an approximation of the time the server needs to process your request, without the data marshalling time on the network and anything, you can either use EXPLAIN ANALYZE (but mysql doesn't have it, and the instrumentation adds overhead), or simply something like "SELECT sum(1) FROM (query to benchmark)", which only returns 1 row, and the sum() overhead is minimal, and it works on most databases. I find it useful because in knowing which portion of the time is spent by the server processing the query, or in data transfer, or in data decoding on the client side, or simply in displaying...