For background, the issue here is that there are three SSI calls that get invoked even on non-serializable transactions: - PredicateLockPageSplit/Combine, during B-tree page splits/combines - PredicateLockTupleRowVersionLink, from heap_update
These have to update any matching SIREAD locks to match the new lock target. If there aren't any serializable transactions, there won't be any, but it still has to check and this requires taking a LWLock. Every other SSI function checks XactIsoLevel and bails out immediately if non-serializable. Like Kevin said, I tested this by removing these three calls and comparing under what I see as worst-case conditions. I used pgbench, an update-mostly workload, in read committed mode. The database (scale factor 100) fit in shared_buffers and was backed by tmpfs so disk accesses didn't enter the picture anywhere. I ran it on a 16-core machine to stress lock contention. Even under these conditions I couldn't reliably see a slowdown. My latest batch of results (16 backends, median of three 10 minute runs) shows a difference well below 1%. In a couple of cases I saw the code with the SSI checks running faster than with them removed, so this difference seems in the noise. Given that result, and considering it's a pretty extreme condition, it probably isn't worth worrying about this too much, but... There's a quick fix: we might as well bail out of these functions early if there are no serializable transactions running. Kevin points out we can do this by checking if PredXact->SxactGlobalXmin is invalid. I would add that we can do this safely without taking any locks, even on weak-memory-ordering machines. Even if a new serializable transaction starts concurrently, we have the appropriate buffer page locked, so it's not able to take any relevant SIREAD locks. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
