Re: Vacuum full progress
От | Scott Marlowe |
---|---|
Тема | Re: Vacuum full progress |
Дата | |
Msg-id | AANLkTi=UkpQzbw+cxb4GNrKoWbdiVaxwgEcmFXj5xcO7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum full progress (Carlos Henrique Reimer <carlos.reimer@opendb.com.br>) |
Ответы |
Re: Vacuum full progress
|
Список | pgsql-general |
On Sun, Sep 5, 2010 at 5:09 AM, Carlos Henrique Reimer <carlos.reimer@opendb.com.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.
В списке pgsql-general по дате отправления: