On Sun, Mar 24, 2013 at 7:03 PM, Atri Sharma <atri.j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
