On Thu, Jan 19, 2012 at 11:29 PM, Greg Smith <g...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
