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 по дате отправления: