On Thu, Jun 6, 2013 at 3:34 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Fri, May 24, 2013 at 11:51 AM, Greg Smith <g...@2ndquadrant.com> wrote: >> >> On 5/24/13 9:21 AM, Robert Haas wrote: >> >>> But I wonder if we wouldn't be better off coming up with a little more >>> user-friendly API. Instead of exposing a cost delay, a cost limit, >>> and various charges, perhaps we should just provide limits measured in >>> KB/s, like dirty_rate_limit = <amount of data you can dirty per >>> second, in kB> and read_rate_limit = <amount of data you can read into >>> shared buffers per second, in kB>. >> >> >> I already made and lost the argument for doing vacuum in KB/s units, so I >> wasn't planning on putting that in the way of this one. > > > I think the problem is that making that change would force people to relearn > something that was already long established, and it was far from clear that > the improvement, though real, was big enough to justify forcing people to do > that. That objection would not apply to a new feature, as there would be > nothing to re-learn. The other objection was that (at that time) we had > some hope that the entire workings would be redone for 9.3, and it seemed > unfriendly to re-name things in 9.2 without much change in functionality, > and then redo them completely in 9.3.
Right. Also, IIRC, the limits didn't really mean what they purported to mean. You set either a read or a dirty rate in KB/s, but what was really limited was the combination of the two, and the relative importance of the two factors was based on other settings in a severely non-obvious way. If we can see our way clear to ripping out the autovacuum costing stuff and replacing them with a read rate limit and a dirty rate limit, I'd be in favor of that. The current system limits the linear combination of those with user-specified coefficients, which is more powerful but less intuitive. If we need that, we'll have to keep it the way it is, but I'm hoping we don't. -- 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
