In vacuum full output, indexes are listed as having been vacuumed along with their table.
Have I misinterpreted this message saying that vacuum is incapable of vacuuming indexes (and reindex is the only option to do so) please?
On 3/25/06, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Peter Eisentraut <peter_e@xxxxxxx> writes:
> Am Freitag, 24. März 2006 05:48 schrieb Tom Lane:
>> Well, the VACUUM FULL algorithm is incapable of shrinking indexes ---
>> the only way is REINDEX, or something else that reconstructs indexes
>> from scratch, such as CLUSTER. One of the things we need to look into
>> is putting more smarts into VACUUM so that it automatically does
>> something reasonable when faced with extreme cases like these.
> If the user is running VACUUM FULL, he has presumably determined that the
> table is too bloated to be recovered in a graceful way, and quite likely the
> indexes are going to be bloated similarly. So seemingly one might as well
> launch a reindexing on the table after VACUUM FULL has done its thing.
> Whether that should be automatic is another question but perhaps the advice
> should be documented somewhere?
Actually, I wonder whether VACUUM FULL shouldn't be thrown away and
replaced by something else entirely. That algorithm only really works
nicely when just a small percentage of the rows need to be moved to
re-compact the table --- if you're moving lots of rows, it makes the
index bloat situation *worse* not better because of the transient need
for index entries pointing to both copies of moved rows. Lazy VACUUM
has become the de-facto standard for situations where there's not a huge
amount of empty space, and so it's not clear where the sweet spot is for
VACUUM FULL anymore. If you've got enough disk space, a rewrite (like
CLUSTER or ALTER TABLE) is going to blow the doors off VACUUM FULL,
let alone VACUUM FULL plus REINDEX. Not to mention that for
sufficiently huge tables, VACUUM FULL fails outright because it runs out
of RAM.
We need to fix CLUSTER to make it MVCC-safe (ie, not discard
recently-dead rows), and it'd be nice to have something like it that
didn't worry about ordering but just did a seqscan of the source table.
Then I'd be inclined to recommend that instead of VACUUM FULL for most
cases of severe bloat.
Unfortunately this all breaks down for shared system catalogs and the
core (nailed-in) catalogs, because we can't change their relfilenodes
and so the crash-safe CLUSTER/REINDEX approach doesn't work. We still
need a new idea or two there.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
