Re: Spreading full-page writes
От | Fujii Masao |
---|---|
Тема | Re: Spreading full-page writes |
Дата | |
Msg-id | CAHGQGwEeep45nBRSBq_DpZC4J++nB8dpj2vQJik_HyLENhsrRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Spreading full-page writes (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Spreading full-page writes
Re: Spreading full-page writes |
Список | pgsql-hackers |
On Tue, May 27, 2014 at 3:57 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 25 May 2014 17:52, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > >> Here's an idea I tried to explain to Andres and Simon at the pub last night, >> on how to reduce the spikes in the amount of WAL written at beginning of a >> checkpoint that full-page writes cause. I'm just writing this down for the >> sake of the archives; I'm not planning to work on this myself. > ... > > Thanks for that idea, and dinner. It looks useful. > > I'll call this idea "Background FPWs" > >> Now, I'm sure there are issues with this scheme I haven't thought about, but >> I wanted to get this written down. Note this does not reduce the overall WAL >> volume - on the contrary - but it ought to reduce the spike. > > The requirements we were discussing were around > > A) reducing WAL volume > B) reducing foreground overhead of writing FPWs - which spikes badly > after checkpoint and the overhead is paid by the user processes > themselves > C) need for FPWs during base backup > > So that gives us a few approaches > > * Compressing FPWs gives A > * Background FPWs gives us B > which look like we can combine both ideas > > * Double-buffering would give us A and B, but not C > and would be incompatible with other two ideas Double-buffering would allow us to disable FPW safely but which would make a recovery slow. So if we adopt double-buffering, I think that we would also need to overhaul the recovery. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: