X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 46800D8466 for ; Tue, 30 Aug 2005 10:12:43 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 58059-01 for ; Tue, 30 Aug 2005 13:12:37 +0000 (GMT) Received: from frank.wiles.org (frank.wiles.org [24.124.39.75]) by svr1.postgresql.org (Postfix) with ESMTP id 8F21BD7837 for ; Tue, 30 Aug 2005 10:12:35 -0300 (ADT) Received: from kungfu (frank.wiles.org [127.0.0.1]) by frank.wiles.org (8.13.1/8.13.1) with SMTP id j7UDCbOR007840; Tue, 30 Aug 2005 08:12:37 -0500 Date: Tue, 30 Aug 2005 08:13:22 -0500 From: Frank Wiles To: "Akshay Mathur" Cc: pgsql-performance@postgresql.org Subject: Re: Observation about db response time Message-Id: <20050830081322.20a13d4f.frank@wiles.org> In-Reply-To: <003401c5ad63$8420d940$9701a8c0@pune.wibhu.com> References: <003401c5ad63$8420d940$9701a8c0@pune.wibhu.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.018 required=5 tests=[AWL=0.018] X-Spam-Level: X-Archive-Number: 200508/514 X-Sequence-Number: 14261 On Tue, 30 Aug 2005 18:35:30 +0530 "Akshay Mathur" wrote: > Hello Friends, > > We were having a database in pgsql7.4.2 The database was responding > very slowly even after full vacuum analyze (select count(*) from > some_table_having_18000_records was taking 18 Sec). > > We took a backup of that db and restored it back. Now the same db on > same PC is responding fast (same query is taking 18 ms). > > But we can't do the same as a solution of slow response. Do anybody > has faced similar problem? Is this due to any internal problem of > pgsql? Is there any clue to fasten the database? This could be because you don't have max_fsm_pages and max_fsm_relations setup correctly or are not doing full vacuums often enough. If your database deletes a ton of data as a matter of course then sometimes a full vacuum will not clear up as much space as it could. Try increasing those configuration values and doing vacuums more often. If you should also explore upgrading to the latest 8.0 as you will no doubt see noticeable speed improvements. --------------------------------- Frank Wiles http://www.wiles.org ---------------------------------