Simon Riggs <si...@2ndquadrant.com> wrote: > Reading the code, IIUC, we check for RW conflicts after each write > but only if the writer is running a serializable transaction. Correct as far as that statement goes. There are cases where predicate lock maintenance is needed when dealing with locked resources; see below. > Am I correct in thinking that there is zero impact of SSI if > nobody is running a serializable transaction? Benchmarks until a recent change actually were coming out slightly faster with the SSI patch. Since there's not other reason that should have been true, that pretty much had to be the random alignment of code on CPU cache boundaries. A recent change canceled that improvement; until we reverted SSI entirely for a comparative benchmark point we briefly thought SSI caused an overall fraction of a percent regression. We've considered changing the "call SSI method which does a quick return if not applicable" technique to "try to call SSI with a macro which skips the call if not applicable", but in the absence of any evidence of a performance hit with the simple, straightforward approach we have held off on that optimization attempt. There are cases where some minimal work is done in SSI for non-serializable transactions: (1) If a tuple which is predicate locked, or sits on a predicate- locked page, is updated, the predicate lock is duplicated for the new tuple. We have found patterns of updates involving four or more transactions where a non-serializable transaction can hide serialization anomalies among serializable transactions if we don't do this. Someone suggested that we could take out this call and just document that serializable transactions may not comply with the standard-defined behavior when there are concurrent non-serializable transactions. We were unable to show a measurable performance hit on this, although this was just with 32 clients hitting a 16 processor machine. There was at least a theoretical possibility that with higher levels of concurrency there could have been a new contention point for a LW lock here which could affect performance. We added a quick return which didn't need to check any locks at the front of this routine which is taken if there are no active serializable transactions on the cluster at the moment of update. (2) Page splits and page combines, even if they are from non-serializable transactions (like autovacuum) must take action if there are predicate locks on the pages involved. Again, there is a fast exit if no serializable transactions are active, and even before that check was added there was not a measurable impact on performance. If any of that isn't clear or leaves some concern, please let me know. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
