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

On Thu, Jan 19, 2012 at 11:29 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> I chewed a bit on Heikki's comment that similarity to the query planning
> parameters might be useful, and Robert's that being able to explain how the
> feature works more easily has value.  I have an initial adjustment of my
> general idea that I think moves usefully in both those directions.
>
> The existing VACUUM cost constants look like this:
>
> vacuum_cost_page_hit = 1
> vacuum_cost_page_miss = 10
> vacuum_cost_page_dirty = 20
>
> These could be adjusted to instead be ratios like the query planner ones
> (seq_page_cost, random_page_cost, etc.), referenced off a value of 1.0 for
> page miss ~= a read is expected:
>
> vacuum_cost_page_hit = 0.1
> vacuum_cost_page_miss = 1.0
> vacuum_cost_page_dirty = 2.0
>
> Now add in the new setting, which is explicitly said to be the read value:
>
> vacuum_cost_read_limit = 8000 # maximum page miss read rate in
> kilobytes/second
>
> And I can shuffle the numbers around internally such that things still work
> exactly the same, at the default parameters.  And then anyone who spends
> time learning how either the query planning or vacuum cost ratio constants
> work will find the learning curve to pick up the other set easier.

That may be a little better, but I still don't think it's worth
breaking backward compatibility for.  I mean, suppose I don't care
about read rate, but I want to limit my dirty data rate to 1MB/s.
What parameters should I set?

> It might be a bit more straightforward yet if things were renamed so it was
> more obvious that page miss~=read, but I haven't seen a good way to do that
> yet.  Renaming the reference cost value to vacuum_cost_page_read has two
> problems.  It makes the backward compatibility issues larger, and it's not
> quite true.  The way I think this should be explained, they really aren't
> the same; that's why I used ~= above.  A page miss is not guaranteed to be a
> read, it just is expected to be one in the worst case.  The read rate that
> vacuum page misses introduce will not be exactly the same as
> vacuum_cost_read_limit--but it will be below that limit, which is all it
> claims to be.

Maybe, but I still think having the read rate limit the dirty rate or
visca versa is *really* weird.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company