On Wed, Jan 15, 2014 at 7:54 AM, Magnus Hagander <mag...@hagander.net> wrote:
> On Wed, Jan 15, 2014 at 3:20 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> We've discussed previously the negative impact of large bulk
>> operations, especially wrt WAL writes. Patch here allows maintenance
>> operations to have their WAL generation slowed down as a replication
>> lag prevention feature.
>> I believe there was originally intended to be some work on I/O rate
>> limiting, but that hasn't happened and is in some ways orthogonal to
>> this patch and we will likely eventually want both.
>> Single new parameter works very similarly to vacuum_cost_delay
>> wal_rate_limit_delay = Xms
> Seems like a really bad name if we are only slowing down some commands -
> that seems to indicate we're slowing down all of them. I think it should be
> something that indicates that it only affects the maintenance commands.
And why should it only affect the maintenance commands anyway, and who
decides what's a maintenance command?
I thought Heroku suggested something like this previously, and their
use case was something along the lines of "we need to slow the system
down enough to do a backup so we can delete some stuff before the disk
fills". For that, it seems likely to me that you would just want to
slow everything down.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: