On Thu, Jul 7, 2011 at 5:54 AM, Florian Pflug <f...@phlo.org> wrote: > In effect, the resulting thing is an LWLock with a partitioned shared > counter. The partition one backend operates on for shared locks is > determined by its backend id. > > I've added the implementation to the lock benchmarking tool at > https://github.com/fgp/lockbench > and also pushed a patched version of postgres to > https://github.com/fgp/postgres/tree/lwlock_part > > The number of shared counter partitions is current 4, but can easily > be adjusted in lwlock.h. The code uses GCC's atomic fetch and add > intrinsic if available, otherwise it falls back to using a per-partition > spin lock.
I think this is probably a good trade-off for locks that are most frequently taken in shared mode (like SInvalReadLock), but it seems like it could be a very bad trade-off for locks that are frequently taken in both shared and exclusive mode (e.g. ProcArrayLock, BufMappingLocks). I don't want to fiddle with your git repo, but if you attach a patch that applies to the master branch I'll give it a spin if I have time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
