Received: from localhost (uranus.hub.org [200.46.204.60]) by postgresql.org (Postfix) with ESMTP id 7E54D9FB256 for ; Wed, 15 Nov 2006 09:32:20 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.60]) (amavisd-new, port 10024) with ESMTP id 03762-03 for ; Wed, 15 Nov 2006 09:32:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.trinitydigital.com.au (unknown [202.134.38.99]) by postgresql.org (Postfix) with ESMTP id ECECF9FB1EC for ; Wed, 15 Nov 2006 09:32:17 -0400 (AST) Received: from [172.17.73.3] (unknown [202.134.38.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.trinitydigital.com.au (Postfix) with ESMTP id 7277EA76; Thu, 16 Nov 2006 00:31:57 +1100 (EST) Message-ID: <455B16CF.6000503@pws.com.au> Date: Thu, 16 Nov 2006 00:31:59 +1100 From: Russell Smith User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "AMIR FRANCO D. JOVEN" CC: pgsql-performance@postgresql.org Subject: Re: Slow SELECT on three or more clients References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/109 X-Sequence-Number: 21879 AMIR FRANCO D. JOVEN wrote: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. Upgrading your version of PostgreSQL to 8.1 will give you significant benefits to performance. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset in > only one client consumes about 0.86 seconds. > The client executes three 'select' statements to perform the task > which consumes 2.58 seconds. > With only one client this is acceptable, but the real problem is as i > add more clients, it goes more and more slower. > > for a single select with one field in one resultset, is 0.86 seconds > normal? You will need to attach the query. EXPLAIN ANALYZE SELECT ... where SELECT ... is your query. That will help us work out what the problem is. 0.86 seconds might be slow for a query that returns 1 row, it might be fast for a query that returns a large set with complex joins and where conditions. Fast and slow are not objective terms. They are very dependent on the query. > > I tried vacuuming and reindexing but to no avail. > the total record count in that particular table is 456,541. > 456,541 is not all that many records. But again you will need to post more information for us to be able to assist. > Thanks in advance. >