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 4661811F66C8 for ; Tue, 4 Apr 2006 12:07:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 28977-02 for ; Tue, 4 Apr 2006 12:07:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62]) by postgresql.org (Postfix) with ESMTP id 6214511F671A for ; Tue, 4 Apr 2006 12:07:53 -0300 (ADT) Received: from dba5.int.libertyrms.com ([10.1.3.44]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FQn8K-0000MU-0U; Tue, 04 Apr 2006 11:07:52 -0400 Message-ID: <44328BC7.1070208@ca.afilias.info> Date: Tue, 04 Apr 2006 11:07:51 -0400 From: Brad Nicholson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Dan Harris CC: PostgreSQL Performance Subject: Re: vacuum full seems to hang on very small table References: <443289E3.7020801@drivefaster.net> In-Reply-To: <443289E3.7020801@drivefaster.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: bnichols@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.178 required=5 tests=[AWL=0.178] X-Spam-Score: 0.178 X-Spam-Level: X-Archive-Number: 200604/45 X-Sequence-Number: 18129 Dan Harris wrote: > I have a table with 1 live row that I found has 115000 dead rows in it ( > from a testing run ). I'm trying to VACUUM FULL the table and it has > run for over 18 hours without completion. Considering the hardware on > this box and the fact that performance seems reasonable in all other > aspects, I'm confused as to why this would happen. The database other > than this table is quite large ( 70 gigs on disk ) and I would expect to > take days to complete but I just did 'vacuum full table_stats'. That > should only do that table, correct? I'm running 8.0.3. VACUUM FULL requires an exclusive lock on the table that it's vacuuming. Chances are something else has a lock on the table is blocking the vacuum from obtaining the necessary lock. Check pg_locks for ungranted locks, you'll probably find that the request from the vacuum is ungranted. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.