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. Drake||Date: 2005-03-01 01:10:11|
|Subject: Re: Development Plans|
|Previous:||From: Bruce Momjian||Date: 2005-03-01 00:38:39|
|Subject: Re: Thread-safe snprintf() vsnprintf() and printf()|
pgsql-general by date
|Next:||From: Tom Lane||Date: 2005-03-01 00:59:15|
|Subject: Re: vacuum_cost_delay & VACUUM holding locks on GIST indexes |
|Previous:||From: Michael Fuhr||Date: 2005-02-28 23:57:27|
|Subject: Re: |