Skip site navigation (1) Skip section navigation (2)

Re: Vacuum time degrading

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Wes <wespvp(at)syntegra(dot)com>
Cc: Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Vacuum time degrading
Date: 2005-03-01 00:53:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Wes <wespvp(at)syntegra(dot)com> writes:
> Why is the vacuum time not going up linearly?

I'm betting that the database is suffering from substantial bloat,
requiring VACUUM to scan through lots of dead space that wasn't there
before.  Check your FSM settings (the tail end of the output from a
full-database VACUUM VERBOSE command would give some info about what you

If you are suffering bloat, the fastest route to a solution would
probably be to CLUSTER your larger tables.  Although VACUUM FULL
would work, it's likely to be very slow.

> There are currently no deletes or modifies to the database - only inserts.

You *certain* about that?  It's hard to see how the vacuum time wouldn't
be linear in table size if there's nothing to do and no dead space.

Again, VACUUM VERBOSE info would be informative (it's sufficient to look
at your larger tables for this).

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2005-03-01 01:10:11
Subject: Re: Development Plans
Previous:From: Bruce MomjianDate: 2005-03-01 00:38:39
Subject: Re: Thread-safe snprintf() vsnprintf() and printf()

pgsql-general by date

Next:From: Tom LaneDate: 2005-03-01 00:59:15
Subject: Re: vacuum_cost_delay & VACUUM holding locks on GIST indexes
Previous:From: Michael FuhrDate: 2005-02-28 23:57:27
Subject: Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group