Re: VACUUM FULL vs dump & restore

From: Aldor <an(at)mediaroot(dot)de>
To: "Ilya A(dot) Kovalenko" <shadow(at)oganer(dot)net>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: VACUUM FULL vs dump & restore
Date: 2005-09-24 11:19:48
Message-ID: 43353654.5040600@mediaroot.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Hello Ilya,

you have to check for yourself which method is faster - just test it
with a stopwatch;-)

You have to take care, because when you make VACUUM FULL, then it
vacuums also the system tables, etc. of postgres.

I'm not sure if this is the same way VACUUM goes through all objects,
but I'd make a customized vacuum, which finds out first every object
which should be vacuumed by:

select relname
from pg_class

You can filter out not wanted objects through the query or when
processing the "VACUUM FULL [object]" or only "VACUUM [object].

In this way I can decide for myself what I want to vacuum, and what I
will do by dump-truncate-restore.

In many cases a normal VACUUM was even faster then the primitive
dump-truncate-restore process. The bottlneck on a VACUUM is as I saw
from my experience on tables with long strings inside and an amount of
hundreds of millions.

Regards,

Aldor

Ilya A. Kovalenko wrote:
> Greetings,
>
> What advantages I lose, when using dump-truncate-restore (table
> or whole DB) instead of performing VACUUM FULL ?
> In both cases I have no access to data, but first is much faster
> (by subjective estimate).
>
> Thank you,
>
> Ilya A. Kovalenko (mailto:shadow(at)oganer(dot)net)
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Aldor 2005-09-24 11:28:45 Re: VACUUM FULL vs dump & restore
Previous Message Ilya A. Kovalenko 2005-09-24 04:56:12 VACUUM FULL vs dump & restore