Re: reducing the overhead of frequent table locks, v4

On Thu, Jun 30, 2011 at 6:28 PM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 27 June 2011 15:13, Robert Haas <robertmhaas(at)gmail(dot)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