From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Excessive CPU usage in StandbyReleaseLocks() |
Date: | 2018-06-20 22:29:21 |
Message-ID: | 20180620222921.qyosyutyzdfozv6m@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-06-21 00:25:03 +1200, David Rowley wrote:
> On 19 June 2018 at 17:43, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> > The problem is that StandbyReleaseLocks() does a linear search of all
> > known AccessExclusiveLocks when a transaction ends. Luckily, since
> > v10 (commit 9b013dc2) that is skipped for transactions that haven't
> > taken any AELs and aren't using 2PC, but that doesn't help all users.
>
> Good to see this getting fixed. My original patch [1] to fix this was
> more along the lines of yours
From that discussion I don't really understand why that wasn't pursued
further. The revision committed, clearly was just continuing to use the
wrong datastructure, and had obvious issues with complexity, just in a
somewhat narrower situation?
> only I partitioned the List in an array indexed by the xid mod size of
> array. I had done this as I thought it would be faster than a hash
> table and would likely see the locks spread evenly over the table.
> IIRC Andres complained and said I should use a hashtable, which I see
> you've done.
It's hard to believe the hashtable is a meaningful bottleneck here. The
primary also uses a hashtable, except it's partitioned & shared, and
thus protected by locks. Also much larger. So it's hard to believe that
we'd need a custom built datastructure to speedup replay...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-06-20 23:35:32 | changing xpath() and xpath_exists() |
Previous Message | Nico Williams | 2018-06-20 22:28:43 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |