On Thu, Jun 30, 2011 at 6:28 PM, Thom Brown <t...@linux.com> wrote: > On 27 June 2011 15:13, Robert Haas <robertmh...@gmail.com> wrote: >> I didn't get a lot of comments on my the previous version of my patch >> to accelerate table locks. >> >> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00953.php >> >> Here's a new version anyway. In this version, I have: >> >> 1. Made pg_locks show fast-path locks as well as regular locks, with a >> new Boolean column to distinguish. >> 2. Renamed fpLWLock to backendLock, on the belief that we're going to >> want something like this for quite a bit more than just this one >> patch. >> 3. Removed some debugging code. > > Are you able to benchmark this again, and possibly get Stefan to give > it a go too?
I probably can, but there's not going to be any significant difference. The patch hasn't changed much. Note that the version where Stefan saw a big performance regression when he pounded the server was actually a combination of this patch and the fast vxid locks patch. If we only apply this one, I believe there will still be enough lock manager contention to stifle the worst of those effects. Of course, even if we apply both, there's only going to be a regression on servers with >32 cores, I think, and even then only when the number of clients is greater than the number of cores. Everyone else will see a benefit. I think that the next thing for me to tackle is the SInvalReadLock spinlock contention, but what I'm really hurting for is some code review. -- 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
