Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 4E9662E00FC for ; Wed, 26 Mar 2008 16:50:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 78458-09 for ; Wed, 26 Mar 2008 16:50:17 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mailout.abaca.com (mailout.abaca.com [75.59.196.2]) by postgresql.org (Postfix) with ESMTP id CEC422E00FD for ; Wed, 26 Mar 2008 16:50:20 -0300 (ADT) Received: from v-abaca-epg.lab.abaca.com (localhost.localdomain [127.0.0.1]) by v-abaca-epg.lab.abaca.com (Postfix-out) with ESMTP id E08C5111741 for ; Wed, 26 Mar 2008 12:53:55 -0700 (PDT) X-Propel-Return-Path: Received: from mailout.abaca.com ([172.16.83.19]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.0.8749 $Rev: 8725 $) id 5uNZr83qjRT0; Wed, 26 Mar 2008 12:53:55 -0700 Received: from mail.abaca.com (unknown [172.16.83.4]) by v-abaca-epg.lab.abaca.com (Postfix-out) with ESMTP id DB362110E03 for ; Wed, 26 Mar 2008 12:53:54 -0700 (PDT) Received: from vinu-ubuntu.abaca (172.16.83.123) by mail.abaca.com (172.16.83.4) with Microsoft SMTP Server id 8.0.744.0; Wed, 26 Mar 2008 12:51:24 -0700 Date: Wed, 26 Mar 2008 12:49:56 -0800 From: Vinubalaji Gopal To: "pgsql-performance@postgresql.org" Subject: vacuum in Postgresql 8.0.x slowing down the database Message-ID: <20080326124956.49e1c13d@vinu-ubuntu.abaca> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.12.0; i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Propel-ID: 5uNZr83qjRT0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200803/492 X-Sequence-Number: 29446 Hey all, I had posted sometime back asking for the best way to perform vacuum with a lower priority - I did tune it up to a lower priority and still noticed that the other database queries are slowing down with a vacuum on one big table. I also tried to upgrade Postgresql to 8.0.15 as suggested and I still could reproduce the problem. It happens when I try to vacuum one particular table which has 9.5 million rows and all the other inserts/selects are slowing down by a factor of 10 times. I am using vacuum_cost_delay = 100 vacuum_cost_limit = 200 Even if I cancel the vacuum operation or let the vacuum complete - the slowdown continues to persist till I restart my application. Whats the best way to analyze the reason Postgresql is slowing down? I had a look at pg_locks (did not know what to look for) and also tried starting postgresql with the debug option using: postmaster -d 5 -D /var/pgdata (saw a lot of output including the query being performed but could not gather anything useful) The big table has never been reindexed and has a primary, unique key with btree index and one foreign key constraint. -- Vinu