vacuum full taking much longer than dump + restore?

Поиск
Список
Период
Сортировка
От Dragan Matic
Тема vacuum full taking much longer than dump + restore?
Дата
Msg-id 441E7AF2.2050202@panforma.co.yu
обсуждение исходный текст
Ответы Re: vacuum full taking much longer than dump + restore?
Список pgsql-general
We have a few larger tables (~3,5 million rows largest, ~ 1 million rows
smallest) on our production database which had at least one column
defined as char(nn) (nn being larger or equal to 60).
I did an alter table where I changed the definition of those columns to
varchar(nn), and after that did a 'UPDATE TABLE some_table SET
column_name = RTRIM(column_name)'.
Since it effectively doubled the number of rows I decided to do a vacuum
full. After some 10 hours I had to stop it since it was monday morning,
and vacuum was blocking the querys. After thad I did a pg_dump and a
restore and it was finished in about an hour and a half, with additional
15-20 minutes of vacuum analyze. I'm guessing that this
dump->restore->analyze has done effectively the same thing what vacuum
full was supposed to do. How is it possible that vacuum full was so
slow, are there some configuration parameters that might be
misconfigured? I am using fedora core 4 with pre-built 8.1.3 rpms.
Server has 2 gb of ram.

Tnx in advance

Dragan Matic


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

Предыдущее
От: david.hoksza@seznam.cz
Дата:
Сообщение: Re: ambuild parameters
Следующее
От: Guido Neitzer
Дата:
Сообщение: Difference between "add column" and "add column" with default