From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
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-19 22:23:52 |
Message-ID: | 4F1897F8.103@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/18/12 4:18 PM, Jim Nasby wrote:
> What about doing away with all the arbitrary numbers completely, and just state data rate limits for hit/miss/dirty?
Since many workloads will have a mix of all three, it still seems like
there's some need for weighing these individually, even if they each got
their own rates. If someone says read=8MB/s and write=4MB/s (the
current effective defaults), I doubt they would be happy with seeing
12MB/s happen.
> BTW, this is a case where it would be damn handy to know if the miss was really a miss or not... in the case where we're already rate limiting vacuum, could we afford the cost of get_time_of_day() to see if a miss actually did have to come from disk?
We certainly might if it's a system where timing information is
reasonably cheap, and measuring that exact area will be easy if the
timing test contrib module submitted into this CF gets committed. I
could see using that to re-classify some misses as hits if the read
returns fast enough.
There's not an obvious way to draw that line though. The "fast=hit" vs.
"slow=miss" transition happens at very different place on SSD vs.
regular disks, as the simplest example. I don't see any way to wander
down this path that doesn't end up introducing multiple new GUCs, which
is the opposite of what I'd hoped to do--which was at worst to keep the
same number, but reduce how many were likely to be touched.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2012-01-19 22:39:41 | Re: Vacuum rate limit in KBps |
Previous Message | Bruce Momjian | 2012-01-19 22:04:53 | Re: pg_upgrade with plpython is broken |