Re: VACUUM FULL versus CLUSTER ON

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: VACUUM FULL versus CLUSTER ON
Дата
Msg-id 1152288027.4948.5.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на VACUUM FULL versus CLUSTER ON  (Sven Willenberger <sven@dmv.com>)
Ответы Re: VACUUM FULL versus CLUSTER ON  (Greg Stark <gsstark@mit.edu>)
Список pgsql-general
[snip]
> as I drop them prior to the huge delete, then create them anew). What
> would be the recommended method for reclaiming the disk space lost due
> to bloat? Dropping the 5 indexes on the table and doing a VACUUM FULL,
> keeping the indexes and doing a VACUUM FULL (does FULL perform the same
> disk moving operations on the indexes as it does on the actual table?),
> dropping the indexes except the primary key and CLUSTER ON primary key,
> keeping the indexes and doing a CLUSTER ON primary key (again, does
> CLUSTER ON just operation on the table proper?)

I won't know for sure, but I guess the least downtime you would get by
not dropping the indexes before the delete, but do a reindex after it.
Then cluster on the primary key...

My reasoning (correct me if I'm wrong): the deletion speed won't be
affected by the indexes, I think deletions don't touch the indexes at
all. The REINDEX command recreates all indexes at once, I think it needs
only one full table scan. That needs the indexes in place, so you
shouldn't drop them. The CLUSTER is a lot faster than VACUUM FULL. The
only problem could be that I think all these operations might take more
disk space than the individual indexing + VACUUM FULL.

Are my assumptions correct ?

Cheers,
Csaba.



В списке pgsql-general по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: duplicated values on primary key field on reindex
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: VACUUM and fsm_max_pages