Re: Vacuum Full is *hideously* slow!

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Vacuum Full is *hideously* slow!
Дата
Msg-id 20081116103829.GA25476@svana.org
обсуждение исходный текст
Ответ на Re: Vacuum Full is *hideously* slow!  ("Phoenix Kiula" <phoenix.kiula@gmail.com>)
Ответы disable/enable trigger and transaction  (Peter Billen <peter@clueless.be>)
Список pgsql-general
On Sun, Nov 16, 2008 at 06:05:40AM +0800, Phoenix Kiula wrote:
> How long should cluster take on a db that's about 5.5GB in size? Is it
> worth doing on a production db? The db is running fast now anyway, so
> the only reason I am even thinking about this is because of the
> results of a VACUUM ANALYZE, which give me this:

How long it takes to cluster depends on how many rows there are in the
table and how ordered they are. How long a VACUUM FULL takes depends on
how big the tables is and how many gaps there are to fill. If you have
a big table (in actual space) but it only has a few rows (it's very
bloated) a cluter will will all the time.

> ---
> INFO:  "links": found 5427 removable, 8876599 nonremovable row
> versions in 483102 pages
> DETAIL:  96 dead row versions cannot be removed yet.
> There were 2135991 unused item pointers.
> 235 pages contain useful free space.
> ---

This table looks fine. Only 235 pages have useful free space. The
483102 pages just means the table is 483102*8K = 3.9GB in size. I
imagine you max_fsm_pages is somewhat larger than 235 pages.

If yo uwant proper estimates for max_fsm_pages you should vacuum the
entire DB, then it'll tell you.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Вложения

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

Предыдущее
От: Tony Caduto
Дата:
Сообщение: Re: 8.3 libpq.dll not working on some versions of windows
Следующее
От: Michelle Konzack
Дата:
Сообщение: Re: Database access over the Internet...