Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Date
Msg-id CAD21AoAWZLgsQVh24VUJiez7Ta1U=exE0sm8LtGM1-X1Tn5GWA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Nov 22, 2017 at 11:32 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 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.
>

Attached latest patch incorporated all comments so far. Please review it.

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Next
From: Jing Wang
Date:
Subject: Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE