Re: Vacuum rate limit in KBps - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Vacuum rate limit in KBps
Date
Msg-id 20120208162221.GG24440@momjian.us
Whole thread Raw
In response to Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Re: Vacuum rate limit in KBps  (Greg Smith <greg@2ndQuadrant.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Text-any concatenation volatility acting as optimization barrier
Next
From: Tom Lane
Date:
Subject: Re: Progress on fast path sorting, btree index creation time