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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
