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 6D43311F655B for ; Tue, 4 Apr 2006 11:59:55 -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 80696-01 for ; Tue, 4 Apr 2006 11:59:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from crestone.coronasolutions.com (crestone.coronasolutions.com [66.45.104.24]) by postgresql.org (Postfix) with ESMTP id 47EA011F6270 for ; Tue, 4 Apr 2006 11:59:52 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by crestone.coronasolutions.com (Postfix) with ESMTP id A44B66441F6 for ; Tue, 4 Apr 2006 08:59:49 -0600 (MDT) Received: from crestone.coronasolutions.com ([127.0.0.1]) by localhost (crestone.coronasolutions.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31191-02 for ; Tue, 4 Apr 2006 08:59:47 -0600 (MDT) Received: from [192.168.1.100] (c-67-165-220-189.hsd1.co.comcast.net [67.165.220.189]) by crestone.coronasolutions.com (Postfix) with ESMTP id 7748E644109 for ; Tue, 4 Apr 2006 08:59:47 -0600 (MDT) Message-ID: <443289E3.7020801@drivefaster.net> Date: Tue, 04 Apr 2006 08:59:47 -0600 From: Dan Harris User-Agent: Thunderbird 1.5 (Macintosh/20060122) MIME-Version: 1.0 To: PostgreSQL Performance Subject: vacuum full seems to hang on very small table Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at drivefaster.net X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200604/44 X-Sequence-Number: 18128 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. Table "public.table_stats" Column | Type | Modifiers ---------------------+-----------------------------+----------- count_cfs | integer | count_ncfs | integer | count_unitactivity | integer | count_eventactivity | integer | min_eventmain | timestamp without time zone | max_eventmain | timestamp without time zone | min_eventactivity | timestamp without time zone | max_eventactivity | timestamp without time zone | geocoding_hitrate | double precision | recent_load | timestamp without time zone | count_eventmain | integer | This is the table structure. Any ideas where to begin troubleshooting this? Thanks.