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
- partial.patch (application/octet-stream) patch
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
-
Move RecoveryLockList into a hash table.
- a40cff8956e8 11.0 landed
- 35750a38b7ab 9.6.10 landed
- c4ccbcc1a2a1 9.4.19 landed
- 12f7d91994d1 9.3.24 landed
- 7bcda60d41cb 9.5.14 landed
- 88554c091101 10.5 landed