> optimization 2: refcount is examined during buffer allocation without > a lock. if it's > 0, buffer is assumed pinned (even though it may not > in fact be) and sweep continues
+1. I think this shall not lead to much problems, since a lost update cannot,IMO, lead to disastrous result. At most, a buffer page can survive for an extra clock sweep. > optimization 3: sweep does not wait on buf header lock. instead, it > does 'try lock' and bails if the buffer is determined pinned. I > believe this to be one of the two critical optimizations +1 again. I believe the try lock will be a sort of filter before the actual check, hence reducing the contention. Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
