On 04/24/2014 07:24 PM, Andres Freund wrote:
On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
Andres Freund <and...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
