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
In response to
pgsql-hackers by date
|Next:||From: Greg Smith||Date: 2010-03-01 18:26:09|
|Subject: Re: Re: Hot Standby query cancellation and Streaming Replication
|Previous:||From: Tom Lane||Date: 2010-03-01 17:04:38|
|Subject: Re: Linux start script updates |