Re: literature on write-ahead logging
От | Robert Haas |
---|---|
Тема | Re: literature on write-ahead logging |
Дата | |
Msg-id | BANLkTinZ1P81cJp7C9_eruLySTSb9ynCMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: literature on write-ahead logging (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: literature on write-ahead logging
Re: literature on write-ahead logging |
Список | pgsql-hackers |
On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> 1. Subdivide XLOG insertion into three operations: (1) allocate space >> in the log buffer, (2) copy the log records into the allocated space, >> and (3) release the space to the buffer manager for eventual write to >> disk. AIUI, WALInsertLock currently covers all three phases of this >> operation, but phase 2 can proceed in parallel. It's pretty easy to >> imagine maintain one pointer that references the next available byte >> of log space (let's call this the "next insert" pointer), and a second >> pointer that references the byte following the last byte known to be >> written (let's call this the "insert done" pointer). > > I think this can be done more simply if instead of a single "insert > done" pointer you have an array of them, one per backend; there's also a > global pointer that can be advanced per the minimum of the bunch, which > you can calculate with some quick locking of the array. You don't need > to sleep at all, except to update the array and calculate the global > ptr, so this is probably also faster. I think looping over an array with one entry per backend is going to be intolerably slow... but it's possible I'm wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: