Re: XLogInsert scaling, revisited
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: XLogInsert scaling, revisited |
| Дата | |
| Msg-id | 51DA96B4.2040609@vmware.com обсуждение исходный текст |
| Ответ на | Re: XLogInsert scaling, revisited (Ants Aasma <ants@cybertec.at>) |
| Ответы |
Re: XLogInsert scaling, revisited
|
| Список | pgsql-hackers |
On 08.07.2013 13:21, Ants Aasma wrote: > On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> Ok, I've committed this patch now. Finally, phew! > > Fantastic work! > >> I simplified the handling of xlogInsertingAt per discussion, and added the >> memory barrier to GetXLogBuffer(). I ran again the pgbench tests I did >> earlier with the now-committed version of the patch (except for some comment >> changes). The results are here: > > I can't see a reason why a full memory barrier is needed at > GetXLogBuffer, we just need to ensure that we read the content of the > page after we check the end pointer from xlblocks. A read barrier is > enough here unless there is some other undocumented interaction. GetXLogBuffer() doesn't read the content of the page - it writes to it (or rather, the caller of GetXLogBarrier() does). The barrier is needed between reading xlblocks (to check that the buffer contains the right page), and writing the WAL data to the buffer. README.barrier says that you need a full memory barrier to separate a load and a store. - Heikki
В списке pgsql-hackers по дате отправления: