On 08/27/2013 01:58 PM, Robert Haas wrote:
> On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> Throttling in the client seems much better to me. TCP is designed to handle
>> a slow client.
>
> Other people have already offered some good points in this area, but
> let me just add one thought that I don't think has been mentioned yet.
> We have a *general* need to be able to throttle server-side resource
> utilization, particularly I/O. This is a problem not only for
> pg_basebackup, but for COPY, CLUSTER, VACUUM, and even things like
> UPDATE. Of all of those, the only one for which we currently have any
> kind of a solution is VACUUM. Now, maybe pg_basebackup also needs its
> own special-purpose solution, but I think we'd do well to consider a
> general I/O rate-limiting strategy and then consider particular needs
> in the light of that framework. In that context, server-side seems
> better to me, because something like CLUSTER isn't going to produce
> anything that the client can effectively limit.
>
In fact I already concluded that server-side control is better and even
started to implement it for the next version of the patch. However the
pg_basebackup is different from VACUUM, CLUSTER, etc. in that it
retrieves the data directly from file system, as opposed to buffers. So
there seems to be little room here for utilization of (future)
'throttling infrastructure'.
// Antonin Houska (Tony)
