Skip site navigation (1) Skip section navigation (2)

Re: Vacuum rate limit in KBps

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum rate limit in KBps
Date: 2012-01-20 15:37:21
Message-ID: CA+TgmoZnzvmyBAzz2-BNYt+xPetH-gxYsBU7SoN_2h4KjdhbBg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 19, 2012 at 11:29 PM, Greg Smith <greg(at)2ndquadrant(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-01-20 15:38:24
Subject: Re: CLOG contention, part 2
Previous:From: Robert HaasDate: 2012-01-20 15:32:43
Subject: Re: CLOG contention, part 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group