On Tue, Apr 09, 2013 at 07:49:51PM -0400, Robert Haas wrote:
> These locks are all SSI-related and they're all really hot. Lock 28
> is SerializableXactHashLock and lock 29 is
> SerializableFinishedListLock; both are acquired an order of magnitude
> more often than any non-SSI lock, and cause two orders of magnitude
> more blocking than any other lock whatsoever. Lock 30 is
> SerializablePredicateLockListLock, which has no exclusive lock
> acquisitions at all on this test, but the shared acquisitions result
> in significant spinlock contention.
This matches what I saw when I looked into this a while ago. I even
started sketching out some plans of how we might deal with it, but
unfortunately I never had much time to work on it, and that seems
unlikely to change any time soon. :-\
As it is, pretty much any operation involving SSI requires acquiring
SerializableXactHashLock (usually exclusive), except for checking
whether a read or write indicates a conflict. That includes starting
and ending a transaction.
Two things make this hard to fix:- SSI is about checking for rw-conflicts, which are inherently about *pairs* of
transactions.This makes it hard to do fine-grained locking, because a lot of operations involve looking at or
modifying the conflict list of more than one transaction.- SerializableXactHashLock protects many things. Besides the
SERIALIZABLEXACTstructures themselves, there's also the free lists for SERIALIZABLEXACTs and RWConflicts, the
SerializableXidHash table, the latest SxactCommitSeqno and SxactGlobalXmin, etc.
I'm trying to swap back in my notes about how to address this. It is
bound to be a substantial project, however.
Dan
--
Dan R. K. Ports UW CSE http://drkp.net/