Re: Patch to improve performance of replay of AccessExclusiveLock

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-03-07T12:13:48Z
Lists: pgsql-hackers

Attachments

On 7 March 2017 at 19:22, David Rowley <david.rowley@2ndquadrant.com> wrote:

>>> That may need tweaking. Likely it could be smaller if we had some sort
>>> of bloom filter to mark if the transaction had obtained any AEL locks,
>>> that way it could skip. Initially I really didn't want to make the
>>> patch too complex. I had thought that a fairly large hash table would
>>> fix the problem well enough, as quite possibly most buckets would be
>>> empty and non empty buckets have short lists.
>>
>> ISTM that we should mark each COMMIT if it has an AEL, so we can avoid
>> any overhead in the common case.
>>
>> So an additional sub-record for the commit/abort wal record, via
>> include/access/xact.h
>
> That would be ideal if we could do that, but doing that for so many
> possible transaction IDs seems impractical.

Don't understand this. I'm talking about setting a flag on
commit/abort WAL records, like the attached.

We just need to track info so we can set the flag at EOXact and we're done.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Move RecoveryLockList into a hash table.