Horton

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-22T02:32:30Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow page lock to conflict among parallel group members.

  2. Allow relation extension lock to conflict among parallel group members.

  3. Add assert to ensure that page locks don't participate in deadlock cycle.

  4. Assert that we don't acquire a heavyweight lock on another object after

  5. Fix unsafe usage of strerror(errno) within ereport().

On Wed, Nov 22, 2017 at 5:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Nov 20, 2017 at 5:19 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Attached updated version patch. I've moved only relation extension
>> locks out of heavy-weight lock as per discussion so far.
>>
>> I've done a write-heavy benchmark on my laptop; loading 24kB data to
>> one table using COPY by 1 client, for 10 seconds. The through-put of
>> patched is 10% better than current HEAD. The result of 5 times is the
>> following.
>>
>> ----- PATCHED -----
>> tps = 178.791515 (excluding connections establishing)
>> tps = 176.522693 (excluding connections establishing)
>> tps = 168.705442 (excluding connections establishing)
>> tps = 158.158009 (excluding connections establishing)
>> tps = 161.145709 (excluding connections establishing)
>>
>> ----- HEAD -----
>> tps = 147.079803 (excluding connections establishing)
>> tps = 149.079540 (excluding connections establishing)
>> tps = 149.082275 (excluding connections establishing)
>> tps = 148.255376 (excluding connections establishing)
>> tps = 145.542552 (excluding connections establishing)
>>
>> Also I've done a micro-benchmark; calling LockRelationForExtension and
>> UnlockRelationForExtension tightly in order to measure the number of
>> lock/unlock cycles per second. The result is,
>> PATCHED = 3.95892e+06 (cycles/sec)
>> HEAD = 1.15284e+06 (cycles/sec)
>> The patched is 3 times faster than current HEAD.
>>
>> Attached updated patch and the function I used for micro-benchmark.
>> Please review it.
>
> That's a nice speed-up.
>
> How about a preliminary patch that asserts that we never take another
> heavyweight lock while holding a relation extension lock?
>

Agreed. Also, since we disallow to holding more than one locks of
different relations at once I'll add an assertion for it as well.

I think we no longer need to pass the lock level to
UnloclRelationForExtension(). Now that relation extension lock will be
simple we can release the lock in the mode that we used to acquire
like LWLock.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center