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: 11317.1109638427@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-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
need).

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

Responses

Browse pgsql-general by date

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

Browse pgsql-hackers by date

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