On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus<j...@agliodbs.com> 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)
I don't think we want to cluster on the primary key. I think we just want to rewrite the table keeping the same physical ordering. >> 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? Well I've certainly seen people whose disks are more than 50% full. They tend to be the same people who want to compact their tables. I can't say whether any of them had a single table with associated indexes that were taking up more than 50% but it's not uncommon to have a single table that dominates your database. > 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. We could deal with the admin scripts by making VACUUM FULL do the new behaviour. But I actually don't really like that. I wold prefer to break VACUUM FULL since anyone doing it routinely is probably mistaken. We could name the command something which is more descriptive like VACUUM REWRITE or VACUUM REBUILD or something like that. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
