Merlin Moncure <mmonc...@gmail.com> writes: > I think there is some very low hanging optimization fruit in the clock > sweep loop. first and foremost, I see no good reason why when > scanning pages we have to spin and wait on a buffer in order to > pedantically adjust usage_count. some simple refactoring there could > set it up so that a simple TAS (or even a TTAS with the first test in > front of the cache line lock as we done automatically in x86 IIRC) > could guard the buffer and, in the event of any lock detected, simply > move on to the next candidate without messing around with that buffer > at all. This could construed as a 'trylock' variant of a spinlock > and might help out with cases where an especially hot buffer is > locking up the sweep. This is exploiting the fact that from > StrategyGetBuffer we don't need a *particular* buffer, just *a* > buffer.
Hm. You could argue in fact that if there's contention for the buffer header, that's proof that it's busy and shouldn't have its usage count decremented. So this seems okay from a logical standpoint. However, I'm not real sure that it's possible to do a conditional spinlock acquire that doesn't create just as much hardware-level contention as a full acquire (ie, TAS is about as bad whether it gets the lock or not). So the actual benefit is a bit less clear. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers