Re: Re: Hot Standby query cancellation and Streaming Replication integration
От | Josh Berkus |
---|---|
Тема | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 4B8BFE7C.4070901@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Re: Hot Standby query cancellation and Streaming Replication integration (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Re: Hot Standby query cancellation and Streaming Replication
integration
Re: Hot Standby query cancellation and Streaming Replication integration |
Список | 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
В списке pgsql-hackers по дате отправления: