On Sun, Feb 3, 2013 at 9:25 AM, Kevin Grittner <kgri...@ymail.com> wrote: > > I was able to confirm two cases where this was a consequence of the > lazy truncate logic which Jan recently fixed, but there are clearly > other problems which I didn't have much of a grasp on prior to this > thread. The only thing I knew for sure was that a bulk load, and > in particular a pg_dump/restore cycle, was a time bomb without > VACUUM FREEZE, and users are often reluctant to add time for that > to their maintenance window. If we can't load tuples as frozen in > the first plance, the next best thing would be to nibble away at > freezing them in the background, so that there is no single big > hit. While proposals here seem to deal with very real problems > which we should fix, I'm not sure that anything here addresses this > issue.
It seems like we already have all the machinery we need for this. Don't run VACUUM FREEZE during the maintenance window, instead at the end of the maintenance window set vacuum_cost_delay to nibble (whatever integer that translates to on your system) and let 'er rip. Since vacuum_cost_delay is session settable, it wouldn't interfere with the setting for other things. The only real problem I see with this is how to restart it so that it picks up where it left off if it should get interrupted. I guess giving vacuumdb new options to set the vacuum_cost settings it runs under would be a handy feature for doing this. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
