Re: truncate/create slowness

Поиск
Список
Период
Сортировка
От Julian Scarfe
Тема Re: truncate/create slowness
Дата
Msg-id 01c801c5361a$68ea6ad0$0600a8c0@Wilbur
обсуждение исходный текст
Ответ на truncate/create slowness  (Joe Maldonado <jmaldonado@webehosting.biz>)
Ответы Re: truncate/create slowness  ("Robin M." <robin@primus.ca>)
Re: truncate/create slowness  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
> It's possible you could get out of this by vacuum full and then reindex
> each catalog, but it might be easier to dump and reload the database ...

I've got a similar issue, but caused by neglect rather than anything to to
with pg_autovacuum.

Do you have any rules of thumb for deciding when a pg_dumpall/restore is
likely to be faster than a vacuum full?  Or perhaps more straightforwardly,
how would you expect the time required for a vacuum full to scale with pages
used and rows in the table?

Thanks

Julian Scarfe



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: storing files in postgres
Следующее
От: "Robin M."
Дата:
Сообщение: Re: truncate/create slowness