Re: Cost limited statements RFC

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cost limited statements RFC
Date: 2013-06-06 19:34:01
Message-ID: CAMkU=1xbobgH7+BvVzR1c+GApQiiaaQT84uX-byLW-0L5RKkgw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-06-06 19:57:02 Re: Redesigning checkpoint_segments
Previous Message Simon Riggs 2013-06-06 19:08:52 Re: [PATCH]Tablesample Submission