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 still think
it's possible to switch to real world units and simplify all of those
parameters. Maybe I'll get the energy to fight this battle again for
9.4. I do have a lot more tuning data from production deployments to
use as evidence now.
I don't think the UI end changes the bulk of the implementation work
though. The time consuming part of this development is inserting all of
the cost delay hooks and validating they work. Exactly what parameters
and logic fires when they are called can easily be refactored later.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com