On Wed, 2009-09-02 at 10:41 -0700, Josh Berkus wrote: > 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.
Right. > > > 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? > No. > 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. > Exactly. > > 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. > Agreed, but I think we shouldn't even put it in the postgresql.conf by default. Just document that it exists. Settings for the sake of settings (even ones that may have a corner case) seem to confuse users. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
