All,
> I'm having a hard time believing that VACUUM FULL really has any
> interesting use-case anymore.
Basically, for:
a) people who don't understand CLUSTER (easily fixed, simply create a
VACUUM FULL command which just does CLUSTER on the primary key)
b) people who are completely out of space on disk and are trying to
shrink the database to free up space.
For (b), I think it's OK to just tell those people that they need to
move the database files or find something else to delete. Most of the
time, they have to do that *anyway* in order for VACUUM FULL to work,
since the transaction log is on the same disk. We just need a little
more documentation, is all.
> The problem use cases we have today are only when you really do have
> enough dead space to clean up that you want to compact the file -- but
> not so much that it's worth rewriting the whole table using CLUSTER or
> ALTER TABLE.
I haven't seen this use-case in the field. I'm not sure that it
actually exists. Anyone run across a case where this made sense?
Recently I actually had a client dump and reload their database rather
than running VACUUM FULL; a reload took 4 hours but VACUUM FULL took
more than 18.
> Perhaps we should go one version with a enable_legacy_full_vacuum
> which defaults to off. That would at least let us hear about use cases
> where people are unhappy with a replacement.
I think we do need to do this, just because people won't have changed
their admin scripts. But the goal should be to dump VACUUM FULL
entirely by 8.6 if we *don't* get serious use-cases.
> I did start a while ago on a replacement which used the existing
> rewrite mechanism to do the equivalent of cluster without changing the
> ordering. I forget where I left that but I could go back and look at
> it. I'll be busy for the next few weeks though so it won't be right
> away.
This would be very helpful.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
