Re: StrategyGetBuffer optimization, take 2 - Mailing list pgsql-hackers

> 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