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 CAD21AoCx3qGDL0gSRimQkY9ygH3OrXgbeZ_qskesyqyFk2OAkA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Sun, Dec 17, 2017 at 12:27 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 5:45 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Here is the result.
>> I've measured the through-put with some cases on my virtual machine.
>> Each client loads 48k file to each different relations located on
>> either xfs filesystem or ext4 filesystem, for 30 sec.
>>
>> Case 1: COPYs to relations on different filessystems(xfs and ext4) and
>> N_RELEXTLOCK_ENTS is 1024
>>
>> clients = 2, avg = 296.2068
>> clients = 5, avg = 372.0707
>> clients = 10, avg = 389.8850
>> clients = 50, avg = 428.8050
>>
>> Case 2: COPYs to relations on different filessystems(xfs and ext4) and
>> N_RELEXTLOCK_ENTS is 1
>>
>> clients = 2, avg = 294.3633
>> clients = 5, avg = 358.9364
>> clients = 10, avg = 383.6945
>> clients = 50, avg = 424.3687
>>
>> And the result of current HEAD is following.
>>
>> clients = 2, avg = 284.9976
>> clients = 5, avg = 356.1726
>> clients = 10, avg = 375.9856
>> clients = 50, avg = 429.5745
>>
>> In case2, the through-put got decreased compare to case 1 but it seems
>> to be almost same as current HEAD. Because the speed of acquiring and
>> releasing extension lock got x10 faster than current HEAD as I
>> mentioned before, the performance degradation may not have gotten
>> decreased than I expected even in case 2.
>> Since my machine doesn't have enough resources the result of clients =
>> 50 might not be a valid result.
>
> I have to admit that result is surprising to me.
>

I think the environment I used for performance measurement did not
have enough resources. I will do the same benchmark on an another
environment to see if it was a valid result, and will share it.

Regards,

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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.
Next
From: Amit Langote
Date:
Subject: Re: pg_(total_)relation_size and partitioned tables