>If we > use the value calculated locally to decide on eviction, the highly > used buffers where this is likely will get at least one clock sweep > cycle of grace time. If they are indeed highly used it's likely that > someone will manage to bump the usage_count in the meanwhile. If they > are not hot, a rare speedup or delay in eviction won't matter much.
Yeah, a buffer page getting an extra clock sweep life in lieu of potential performance improvement isn't much of a cost to pay. 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. 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. > Getting rid of memory barriers associated with locking in the clock > sweep will pipeline the loads and stores and so should bring on a good > performance increase for scanning large swathes of buffer headers. > This does sound interesting. If the Jenkins based performance farm gets ready, we can do some tests and see the kind of results we get. 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
