On 2013-06-06 12:34:01 -0700, Jeff Janes wrote: > On Fri, May 24, 2013 at 11:51 AM, Greg Smith <greg@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.
I don't find that argument very convincing. Since you basically can translate the current variables into something like the above variables with some squinting we sure could have come up with some way to keep the old definition and automatically set the new GUCs and the other way round.
That may be, but it was not what the patch that was submitted did. And I don't think the author or the reviewers were eager to put in the effort to make that change, which would surely be quite a bit more work than the original patch was in the first place. Also, I'm not sure that such a complexity would even be welcomed. It sounds like an ongoing maintenance cost, and I'm sure the word "baroque" would get thrown around.
Anyway, I don't think that resistance to making user visible changes to old features should inhibit us from incorporating lessons from them into new features.
guc.c should even have enough information to prohibit setting both in the config file...
Is there precedence/infrastructure for things like that? I could see uses for mutually exclusive complexes of configuration variables, but I wouldn't even know where to start in implementing such.