Skip site navigation (1) Skip section navigation (2)

Re: vacuum full 100 mins plus?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: vacuum full 100 mins plus?
Date: 2004-07-15 04:36:43
Message-ID: 16532.1089866203@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> A long time ago, in a galaxy far, far away, PHatcher(at)macys(dot)com (Patrick Hatcher) wrote:
>> Answered my own question.  I gave up the vacuum full after 150 mins.  I was
>> able to export to a file, vacuum full the empty table, and reimport in less
>> than 10 mins.  I suspect the empty item pointers and the sheer number of
>> removable rows was causing an issue.

> In that case, you'd be a little further better off if the steps were:
>  - drop indices;
>  - copy table to file (perhaps via pg_dump -t my_table);
>  - truncate the table, or drop-and-recreate, both of which make
>    it unnecessary to do _any_ vacuum of the result;
>  - recreate indices, probably with SORT_MEM set high, to minimize
>    paging to disk
>  - analyze the table (no need to vacuum if you haven't created any
>    dead tuples)
>  - cut SORT_MEM back down to "normal" sizes

Rather than doing all this manually, you can just CLUSTER on any handy
index.  In 7.5, another possibility is to issue one of the forms of
ALTER TABLE that force a table rewrite.

The range of usefulness of VACUUM FULL is really looking narrower and
narrower to me.  I can foresee a day when we'll abandon it completely.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2004-07-15 04:52:38
Subject: Re: Odd sorting behaviour
Previous:From: Christopher BrowneDate: 2004-07-15 02:21:29
Subject: Re: vacuum full 100 mins plus?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group