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 54FE5D79A5 for ; Sat, 27 Aug 2005 13:03:09 -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 65600-04 for ; Sat, 27 Aug 2005 16:03:06 +0000 (GMT) Received: from mailserv.pune.wibhu.com (unknown [210.212.168.94]) by svr1.postgresql.org (Postfix) with ESMTP id 142E4D6F81 for ; Sat, 27 Aug 2005 13:03:03 -0300 (ADT) Received: from mailserv.pune.wibhu.com (localhost.localdomain [127.0.0.1]) by mailserv.pune.wibhu.com (8.12.8/8.12.5) with ESMTP id j7RFwwrw018599 for ; Sat, 27 Aug 2005 21:28:59 +0530 Received: (from apache@localhost) by mailserv.pune.wibhu.com (8.12.8/8.12.8/Submit) id j7RFwvQj018597; Sat, 27 Aug 2005 21:28:57 +0530 X-Authentication-Warning: mailserv.pune.wibhu.com: apache set sender to akshay@airtightnetworks.net using -f Received: from 192.168.1.175 (SquirrelMail authenticated user akshay) by mailserv with HTTP; Sat, 27 Aug 2005 21:28:57 +0530 (IST) Message-ID: <2527.192.168.1.175.1125158337.squirrel@mailserv> Date: Sat, 27 Aug 2005 21:28:57 +0530 (IST) Subject: Observation about db response time From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.178 required=5 tests=[NO_REAL_NAME=0.178] X-Spam-Level: X-Archive-Number: 200508/521 X-Sequence-Number: 14268 Hello Friends, We were having a database in pgsql7.4. The database was responding very slowly even after full vacuum (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 fasteen the database? Regards, akshay