On Sun, Mar 24, 2013 at 7:03 PM, Atri Sharma <atri.jiit@gmail.com> wrote:
> So, essentially, we decide locally which page to evict, then try to
> get a lock on the header only when we want to evict the victim page?
> Sounds like the contention for the header should go down considerably.
Not exactly locally, the idea is still to use the shared buffer header
structures. We just accept any errors in usage_count coming from data
races. This won't solve buffer header contention as modifying
usage_count still brings the cacheline in an exclusive state. It does
help with reducing the time BufferFreeListLock is held and it
eliminates spinning on the clocksweep side so only queries that access
the contended buffer are hurt by spinning.
> Unlocked incrementing/decrementing of USAGE_COUNT may lead to the
> values of USAGE_COUNT differing from the actual value they should be
> having by 1 or 2 counts in case of high contention buffer pages, which
> shouldn't matter, as they are in high contention. I agree, it is
> likely that a process(s) will increase the usage_count anyways.
There is no point in an unlocked increment as this is done in
conjunction with a buffer pin that requires the header spinlock
anyway.
Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de