On Tue, Sep 1, 2009 at 2:58 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > We get beat up on a regular basis about "spikes" in response time; > why would you want to have vacuum creating one when it doesn't need to?
Isn't this sync commit just going to do the same thing that the wal writer is going to do in at most 200ms anyways? > As for the FULL case, the sync commit is to try to protect a horribly > unsafe kluge that should go away entirely (if vacuum full itself doesn't > go away entirely). I'm all for throwing away VACUUM FULL btw. I was thinking of proposing that we replace it with something like CLUSTER which just rewrites the tuples in the order it finds them. The use cases where VACUUM FULL wins currently are where storing two copies of the table and its indexes concurrently just isn't practical. Also perhaps tables where there are too many large indexes to make rebuilding them all in one maintenance window practical. I don't see any way to address these problems without something as complex as xvac and moved_in/moved_off and without the index bloat problems. I think we could improve the i/o access patterns we have currently which make vacuum full so slow, but the fundamental problems would remain. So the question is whether those use cases are worth keeping our existing vacuum full for or whether we could do without it and just recommend partitioning for people with tables large enough to make table rewrites impractical. -- 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
