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 CAD21AoBn8WbOt21MFfj1mQmL2ZD8KVgMHYrOe1F5ozsQC4Z_hw@mail.gmail.com
Whole thread Raw
In response to RE: [HACKERS] Moving relation extension locks out of heavyweight lock manager  ("Alex Ignatov" <a.ignatov@postgrespro.ru>)
List pgsql-hackers
On Tue, May 22, 2018 at 12:05 AM, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:
>
>
> --
> Alex Ignatov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
> -----Original Message-----
> From: Alex Ignatov <a.ignatov@postgrespro.ru>
> Sent: Monday, May 21, 2018 6:00 PM
> To: 'Robert Haas' <robertmhaas@gmail.com>; 'Andres Freund' <andres@anarazel.de>
> Cc: 'Masahiko Sawada' <sawada.mshk@gmail.com>; 'Michael Paquier' <michael@paquier.xyz>; 'Mithun Cy'
<mithun.cy@enterprisedb.com>;'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> 
> Subject: RE: [HACKERS] Moving relation extension locks out of heavyweight lock manager
>
>
>
>
> -----Original Message-----
> From: Robert Haas <robertmhaas@gmail.com>
> Sent: Thursday, April 26, 2018 10:25 PM
> To: Andres Freund <andres@anarazel.de>
> Cc: Masahiko Sawada <sawada.mshk@gmail.com>; Michael Paquier <michael@paquier.xyz>; Mithun Cy
<mithun.cy@enterprisedb.com>;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> 
> Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
>
> On Thu, Apr 26, 2018 at 3:10 PM, Andres Freund <andres@anarazel.de> wrote:
>>> I think the real question is whether the scenario is common enough to
>>> worry about.  In practice, you'd have to be extremely unlucky to be
>>> doing many bulk loads at the same time that all happened to hash to
>>> the same bucket.
>>
>> With a bunch of parallel bulkloads into partitioned tables that really
>> doesn't seem that unlikely?
>
> It increases the likelihood of collisions, but probably decreases the number of cases where the contention gets
reallybad. 
>
> For example, suppose each table has 100 partitions and you are bulk-loading 10 of them at a time.  It's virtually
certainthat you will have some collisions, but the amount of contention within each bucket will remain fairly low
becauseeach backend spends only 1% of its time in the bucket corresponding to any given partition. 
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>
> Hello!
> I want to try to test this patch on 302(704 ht) core machine.
>
> Patching on master (commit 81256cd05f0745353c6572362155b57250a0d2a0) is ok but got some error while compiling :

Thank you for reporting.
Attached an rebased patch with current HEAD.

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Problem while updating a foreign table pointing to apartitioned table on foreign server
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [doc fix] Add operation of freeing output SQLDA