Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Date
Msg-id 4F5666C0.5030304@enterprisedb.com
Whole thread Raw
In response to Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Checksums, state of play
Next
From: Marko Kreen
Date:
Subject: Re: [9.2] Confusion over CacheRegisterSyscacheCallback