Re: Vacuum rate limit in KBps

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Vacuum rate limit in KBps
Дата
Msg-id 20120208162221.GG24440@momjian.us
обсуждение исходный текст
Ответ на Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Re: Vacuum rate limit in KBps  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Wed, Feb 08, 2012 at 09:56:17AM -0500, Robert Haas wrote:
> > This is all fine, but what does it have to do with the current patch?  I
> > mean, if we change vacuum to do some stuff differently, it's still going
> > to have to read and dirty pages and thus account for I/O.
> 
> Yeah, I drifted off topic there a bit.  I think the only relevant
> point in all that is that even if we all agreed that this is an
> improvement, I'd be reluctant to slap a band-aid on something that I
> think needs surgery.

Agreed.  I see this only as short-term fix that will be changed in the
next release if we really decide to tackle the problem.  What percentage
of our userbase are going to ever adjust these settings --- <1%, for
sure.

What we have now just isn't cutting it for 99% of our users, and we need
to address that if we are going to ever make any real headway here.

Why can't vacuum handle things automatically like checkpoint smoothing? 
Why can't it detect when it is falling behind and speed up?  Why can't
it see as busy background writer and slow down?   Unless we answer
these questions, we are not solving the problem for 99% of our users.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Text-any concatenation volatility acting as optimization barrier
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Progress on fast path sorting, btree index creation time