From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL Rate Limiting |
Date: | 2014-01-15 04:53:24 |
Message-ID: | 52D61444.4040303@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/14/14, 8:20 PM, Simon Riggs 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
From a replication standpoint, I think it would be a lot nicer if this also (or instead) considered the replication delay we were currently experiencing.
Related to that... it would be extremely useful to us if we could similarly rate limit certain backend operations, for the purpose of not overloading the database or replication. That's fairly unrelated except that sometimes you might want to WAL rate limit a backend operation, besides just COPY.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-01-15 04:53:59 | Re: shared memory message queues |
Previous Message | Tatsuo Ishii | 2014-01-15 04:12:37 | Portal suddenly disappears? |