Re: VACUUM delay (was Re: What's planned for 7.5?)
От | Jan Wieck |
---|---|
Тема | Re: VACUUM delay (was Re: What's planned for 7.5?) |
Дата | |
Msg-id | 400544E3.8030709@Yahoo.com обсуждение исходный текст |
Ответ на | VACUUM delay (was Re: What's planned for 7.5?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Christopher Browne <cbbrowne@libertyrms.info> writes: >> "Stephen" <jleelim@xxxxxxx.com> writes: >>> Any chance we'll see the VACUUM delay patch (throttle) get into 7.5? > >> The hope, in 7.5, is to have ARC, which is the "super-duper-duper" >> version, working. > > Actually, I'm not sure that ARC should be considered to supersede the > usefulness of a per-page delay in VACUUM. ARC should prevent VACUUM > from trashing the contents of Postgres' shared buffer arena, but it > won't do much of anything to prevent VACUUM from trashing the kernel > buffer contents. And it definitely won't do anything to help if the > real problem is that you're short of disk bandwidth and VACUUM's extra > I/O demand pushes your total load over the knee of the response-time > curve. What you need then is a throttle. > > The original patch I posted was incomplete for a number of reasons, > but I think it may still be worth working on. Jan, any comments? I agree that there is considerable value in IO distribution. As such I already have the basics of the Background Writer in there. I left out the vacuum delay since I thought it was good enough to proove that there is low hanging fruit, but that it was far from what I'd call a solution. Ideally Vacuum would coordinate it's IO not only against some GUC variables, but also against the BGWriter+BufStrategy combo. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: