Re: Vacuum Full is *hideously* slow! - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Vacuum Full is *hideously* slow!
Date
Msg-id 20081116103829.GA25476@svana.org
Whole thread Raw
In response to Re: Vacuum Full is *hideously* slow!  ("Phoenix Kiula" <phoenix.kiula@gmail.com>)
Responses disable/enable trigger and transaction  (Peter Billen <peter@clueless.be>)
List 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.

Attachment

pgsql-general by date:

Previous
From: Tony Caduto
Date:
Subject: Re: 8.3 libpq.dll not working on some versions of windows
Next
From: Michelle Konzack
Date:
Subject: Re: Database access over the Internet...