On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote: > Even though this didn't show any difference in Dan's performance > tests, it seems like reasonable insurance against creating a new > bottleneck in very high concurrency situations. > > Dan, do you have a patch for this, or should I create one?
Sure, patch is attached. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c index f02d5d5..48ff9cc 100644 --- a/src/backend/storage/lmgr/predicate.c +++ b/src/backend/storage/lmgr/predicate.c @@ -2275,6 +2275,18 @@ PredicateLockTupleRowVersionLink(const Relation relation, TransactionId oldxmin, newxmin; + /* + * Bail out quickly if there are no serializable transactions + * running. + * + * It's safe to do this check without taking any additional + * locks. Even if a serializable transaction starts concurrently, + * we know it can't take any SIREAD locks on the modified tuple + * because the caller is holding the associated buffer page lock. + */ + if (!TransactionIdIsValid(PredXact->SxactGlobalXmin)) + return; + oldblk = ItemPointerGetBlockNumber(&(oldTuple->t_self)); oldoff = ItemPointerGetOffsetNumber(&(oldTuple->t_self)); oldxmin = HeapTupleHeaderGetXmin(oldTuple->t_data); @@ -2633,6 +2645,15 @@ PredicateLockPageSplit(const Relation relation, const BlockNumber oldblkno, PREDICATELOCKTARGETTAG newtargettag; bool success; + /* + * Bail out quickly if there are no serializable transactions + * running. As with PredicateLockTupleRowVersionLink, it's safe to + * check this without taking locks because the caller is holding + * the buffer page lock. + */ + if (!TransactionIdIsValid(PredXact->SxactGlobalXmin)) + return; + if (SkipSplitTracking(relation)) return;
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
