Re: Database performance post-VACUUM FULL

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Karl Wright" <kwright(at)metacarta(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Database performance post-VACUUM FULL
Date: 2009-10-01 13:25:04
Message-ID: 4AC46760020000250002B52E@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Karl Wright <kwright(at)metacarta(dot)com> wrote:

> when database maintenance takes place (which consists of a VACUUM
> FULL operation, and some table REINDEX operations)

Besides providing the information requested by Robert, can you explain
why you chose to use VACUUM FULL? The FULL option is only really
useful in a small set of unusual use cases for recovery from serious
problems. In most cases it will do more harm than good. If
autovacuum isn't covering your need by itself, a VACUUM of the
database, usually with the ANALYZE option and *possibly* with the
FREEZE option, is almost always adequate, without resorting to the
pain of VACUUM FULL.

If you've run VACUUM FULL without a REINDEX of *all* indexes *after*
the VACUUM FULL, you've probably seriously bloated your indexes. You
may also have shuffled around the rows to positions where you're doing
more random access than before. CLUSTER would be one way to fix both
problems, although if you've bloated your system tables you might be
best off recreating your database with the output from pg_dump.. But
you might want to provide the information Robert requested to confirm
the nature of the problem before attempting to fix it....

-Kevin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-10-01 14:53:25 Re: long running insert statement
Previous Message Claus Guttesen 2009-10-01 10:37:10 Re: Best suiting OS