On Sun, Jan 15, 2012 at 12:24 AM, Greg Smith <g...@2ndquadrant.com> wrote:
> If you then turn that equation around, making the maximum write rate the > input, for any given cost delay and dirty page cost you can solve for the > cost limit--the parameter in fictitious units everyone hates. It works like > this, with the computation internals logged every time they run for now: > > #vacuum_cost_rate_limit = 4000 # maximum write rate in kilobytes/second > LOG: cost limit=200 based on rate limit=4000 KB/s delay=20 dirty cost=20 The computation seems to be suffering from some kind of overflow: cost limit=50 based on rate limit=1000 KB/s delay=20 dirty cost=20 cost limit=100 based on rate limit=2000 KB/s delay=20 dirty cost=20 cost limit=150 based on rate limit=3000 KB/s delay=20 dirty cost=20 cost limit=200 based on rate limit=4000 KB/s delay=20 dirty cost=20 cost limit=250 based on rate limit=5000 KB/s delay=20 dirty cost=20 cost limit=1 based on rate limit=6000 KB/s delay=20 dirty cost=20 cost limit=1 based on rate limit=7000 KB/s delay=20 dirty cost=20 cost limit=1 based on rate limit=8000 KB/s delay=20 dirty cost=20 Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
