From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: WAL insert delay settings |
Date: | 2019-02-13 14:57:27 |
Message-ID: | 22495.1550069847@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On February 13, 2019 1:16:07 PM GMT+01:00, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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 just delay 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
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2019-02-13 15:03:04 | Re: libpq compression |
Previous Message | Dmitry Dolgov | 2019-02-13 14:54:10 | Re: libpq compression |