Re: WAL insert delay settings

On 13.02.2019 19:57, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On February 13, 2019 1:16:07 PM GMT+01:00, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>>> One idea to address this is to slow down WAL-generating maintenance
>>> operations.  This is similar to the vacuum delay.  Where the vacuum
>>> delay counts notional I/O cost before sleeping, here we would count how
>>> much WAL has been generated and sleep after some amount.
> 
>> Interesting idea, not yet quite sure what to think. But I don't think the way you did it is acceptable - we can't
justdelay while holding buffer locks, in critical sections, while not interruptible.
 
> 
> Yeah.  Maybe it could be done in a less invasive way by just having the
> WAL code keep a running sum of how much WAL this process has created,
> and then letting the existing vacuum-delay infrastructure use that as
> one of its how-much-IO-have-I-done inputs.
> 
> Not sure if that makes the tuning problem easier or harder, but
> it seems reasonable on its face to count WAL emission as I/O.
> 
>             regards, tom lane

Also we can add a 'soft' clause to DML queries. It will some abstraction 
for background query execution. It can contain the WAL write velocity 
limit parameter (as Tom proposed) and may some another.

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company