From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Date: | 2010-03-01 17:50:52 |
Message-ID: | 4B8BFE7C.4070901@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-03-01 18:26:09 | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | Tom Lane | 2010-03-01 17:04:38 | Re: Linux start script updates |