Hi,
I thought about this approach but this gave big troubles in the past.
Basically the problem of this is that views and functions will still work on
the old_table_bak and not the new_table.
This can work but all views and functions linked to the old_table must be
recreated. Something that needs
On Sun, Sep 5, 2010 at 5:09 AM, Carlos Henrique Reimer
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 p
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 anothe
On 5 Sep 2010, at 12:13, Carlos Henrique Reimer wrote:
> Hi,
>
> I need to shrick a table with 102 GB and approximately 380.000.000 rows.
What exactly are you trying to accomplish? You may be saving some space
temporarily by running vacuum full and reindex, but the database size will
probably
Hi,
I need to shrick a table with 102 GB and approximately 380.000.000 rows.
There is a vacuum full running for 13 hours and the only messages a get are:
INFO: vacuuming "public.posicoes_controles"
INFO: "posicoes_controles": found 43960 removable, 394481459 nonremovable
row versions in 133089
