Re: 8.2rc1: vacuum full fills up disk space

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Thomas H(dot)" <me(at)alternize(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: 8.2rc1: vacuum full fills up disk space
Date: 2006-11-27 17:35:48
Message-ID: 456B21F4.6090301@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thomas H. wrote:
>>> this somehow sounds buggy:
>>
>> vacuum full absolutely *will* bloat your index, if run on a
>> heavily-modified table. I do not think it will bloat pg_xlog by itself
>> however; are you sure you don't have some other open transactions?
>
> well yes, as the system is "live", users are browsing the website. but
> all queries that try to access the table in question are stalled at the
> moment. when querying server status i'm seeing lots of queries that are
> waiting for access to the table.
>
> would vacuum freeze be faster?

Vacuum freeze won't move tuples so it won't reclaim any more space than
a normal vacuum. Cluster, however, rewrites the whole table and compacts
the space, and runs faster than vacuum full on a badly bloated table. It
will also recreate all indexes.

In the future, instead of updating a whole table with UPDATE, you should
consider doing a SELECT INTO to create a new table, dropping the old
table and renaming the new one in place of the old one.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Patrick Hayes 2006-11-27 18:04:05 BUG #2785: Exception Issue
Previous Message Jeremy Haile 2006-11-27 17:14:00 Re: fsync and semctl errors with 8.1.5/win32