Re: Vacuum full progress

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Carlos Henrique Reimer <carlos(dot)reimer(at)opendb(dot)com(dot)br>
Cc: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, pgsql-general(at)postgresql(dot)org
Subject: Re: Vacuum full progress
Date: 2010-09-05 19:46:57
Message-ID: AANLkTi=UkpQzbw+cxb4GNrKoWbdiVaxwgEcmFXj5xcO7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Sep 5, 2010 at 5:09 AM, Carlos Henrique Reimer
<carlos(dot)reimer(at)opendb(dot)com(dot)br> wrote:
> Hi Alban,
>
> The need for the vacuum full is because there were a problem with the daily
> schedulled vacuum analyze and autovacuum regarding the max_fsm_pages. As it
> was underestimated the vacuum process was not able to flag the pages to be
> reused.
>
> I've cancelled the vacuum full and will think another approach. Maybe a
> CLUSTER can do the work. Will start a CLUSTER and see if I can check the
> progress looking the size of the new table relfilenode. It will probably
> have less than 102 GB.

fastest way if you can afford downtime is something like;

select * into new_table from old_table order by pkcol;
alter old_table rename to old_table_bak;
alter new_table rename to old_table;

--
To understand recursion, one must first understand recursion.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Carlos Henrique Reimer 2010-09-05 20:40:19 Re: Vacuum full progress
Previous Message Cédric Villemain 2010-09-05 15:37:48 Re: How can I use parameters in plain sql