On Thu, Jun 6, 2013 at 2:27 PM, Andres Freund <and...@2ndquadrant.com>wrote:
> On 2013-06-06 12:34:01 -0700, Jeff Janes 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. > > 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. Cheers, Jeff
