Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
От | Heikki Linnakangas |
---|---|
Тема | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Дата | |
Msg-id | 4F5666C0.5030304@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
|
Список | pgsql-hackers |
On 06.03.2012 17:12, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >> On 06.03.2012 14:52, Fujii Masao wrote: >>> This also strikes me that the usage of the spinlock insertpos_lck might >>> not be OK in ReserveXLogInsertLocation() because a few dozen instructions >>> can be performed while holding the spinlock.... > >> I admit that block is longer than any of our existing spinlock blocks. >> However, it's important for performance. I tried using a lwlock earlier, >> and that negated the gains. So if that's a serious objection, then let's >> resolve that now before I spend any more time on other aspects of the >> patch. Any ideas how to make that block shorter? > > How long is the current locked code exactly --- does it contain a loop? Perhaps best if you take a look for yourself, the function is called ReserveXLogInsertLocation() in patch. It calls a helper function called AdvanceXLogRecPtrToNextPage(ptr), which is smalland could be inlined. It does contain one loop, which iterates once for every WAL page the record crosses. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: