On 2/28/10 7:00 PM, Greg Smith wrote: > The main problem with setting vacuum_defer_cleanup_age high isn't > showing it works, it's a pretty simple bit of code. It's when you > recognize that it penalizes all cleanup all the time, whether or not the > standby is actually executing a long-running query or not, that you note > the second level of pain in increasing it. Returning to the idea of > "how is this different from a site already in production?", it may very > well be the case that a site that sets vacuum_defer_cleanup_age high > enough to support off-peak batch reporting cannot tolerate how that will > impact vacuums during their peak time of day. The XID export > implementation sidesteps that issue by only making the vacuum delay > increase when queries that require it are running, turning this back > into a standard "what's the best time of day to run my big reports?" > issue that people understand how to cope with already.
I don't think that defer_cleanup_age is a long-term solution. But we need *a* solution which does not involve delaying 9.0. And I think we can measure bloat in a pgbench test, no? When I get a chance, I'll run one for a couple hours and see the difference that cleanup_age makes. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
