Re: WAL insert delay settings
От | Tom Lane |
---|---|
Тема | Re: WAL insert delay settings |
Дата | |
Msg-id | 22495.1550069847@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WAL insert delay settings (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: WAL insert delay settings
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: