Re: Cost limited statements RFC

On Thu, Jun 6, 2013 at 2:27 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> On 2013-06-06 12:34:01 -0700, Jeff Janes wrote:
> > On Fri, May 24, 2013 at 11:51 AM, Greg Smith <greg(at)2ndquadrant(dot)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