On Tue, May 22, 2018 at 12:05 AM, Alex Ignatov <[email protected]> wrote: > > > -- > Alex Ignatov > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > > -----Original Message----- > From: Alex Ignatov <[email protected]> > Sent: Monday, May 21, 2018 6:00 PM > To: 'Robert Haas' <[email protected]>; 'Andres Freund' > <[email protected]> > Cc: 'Masahiko Sawada' <[email protected]>; 'Michael Paquier' > <[email protected]>; 'Mithun Cy' <[email protected]>; 'Tom Lane' > <[email protected]>; 'Thomas Munro' <[email protected]>; 'Amit > Kapila' <[email protected]>; 'PostgreSQL-development' > <[email protected]> > Subject: RE: [HACKERS] Moving relation extension locks out of heavyweight > lock manager > > > > > -----Original Message----- > From: Robert Haas <[email protected]> > Sent: Thursday, April 26, 2018 10:25 PM > To: Andres Freund <[email protected]> > Cc: Masahiko Sawada <[email protected]>; Michael Paquier > <[email protected]>; Mithun Cy <[email protected]>; Tom Lane > <[email protected]>; Thomas Munro <[email protected]>; Amit > Kapila <[email protected]>; PostgreSQL-development > <[email protected]> > Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight > lock manager > > On Thu, Apr 26, 2018 at 3:10 PM, Andres Freund <[email protected]> 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 really bad. > > For example, suppose each table has 100 partitions and you are bulk-loading > 10 of them at a time. It's virtually certain that you will have some > collisions, but the amount of contention within each bucket will remain > fairly low because each 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
extension-lock-v13.patch
Description: Binary data
