Re: slow startup due to LWLockAssign() spinlock

On 04/24/2014 07:24 PM, Andres Freund wrote:
> On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>>> On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
>>>> Another idea is to add an LWLockAssignBatch(int) function that assigns a
>>>> range of locks in one call. That would be very simple, and I think it would
>>>> be less likely to break things than a new global flag. I would be OK with
>>>> sneaking that into 9.4 still.
>>
>>> I don't really see the advantage tbh. Assuming we always can avoid the
>>> spinlock initially seems simple enough - and I have significant doubts
>>> that anything but buffer locks will need enough locks that it matters
>>> for other users.
>>
>> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
>> proposed patch. LWLockAssign is a low-level function that has no business
>> making risky assumptions about the context it's invoked in.
>
> I don't think LWLockAssignBatch() is that easy without introducing
> layering violations. It can't just return a pointer out of the main
> lwlock array that then can be ++ed clientside because MainLWLockArray's
> stride isn't sizeof(LWLock).

Well, it could copy the pointers to an array of pointers that the caller
provides. Or palloc an array and return that. Allocating a large enough
array to hold NBuffers locks might not be nice, but if you do it in
batches of, say, 1k locks, that would make it fast enough. Makes the
caller a bit more complicated, but still might be worth it.

- Heikki