Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Also there's no attempt to not inflate usage_count, which means that > synchronized scans will spoil the buffer cache as if we didn't have the > buffer ring patch.
As I said, these patches are hardly independent. > If there's no easy solution, I think we could live > with that, but Greg's suggestion of bumping the usage_count in PinBuffer > instead of UnpinBuffer sounds like a nice solution to me. After thinking about it more, I'm a bit hesitant to do that because it will change the interaction with the clock sweep for buffers that stay pinned for awhile. I had suggested making the clock sweep not decrement usage_count of a pinned buffer, but I think that would change the fairness of the algorithm. OTOH it may not matter that much if we just move the usage_count increment and leave the clock sweep alone. Do we have any decent way of measuring the effectiveness of the clock-sweep allocation algorithm? I also thought about having ReadBuffer decrement the usage count when it has a nondefault strategy and finds the buffer already in cache; this would then cancel out the later unconditional increment in UnpinBuffer. But that makes twice as many cycles spent holding the buffer spinlock. Either one of these methods would require PinBuffer to be aware of the strategy argument, which it is not at present. OTOH with the first way we could get rid of the "normalAccess" argument to UnpinBuffer, so there's some net conservation of cruft I guess. I think I had originally given this task to UnpinBuffer on the theory that we'd have better information at unpin time than pin time about what the buffer state had been and thus be able to make smarter decisions about whether to bump the access count or not. But at the moment it doesn't seem that we really need any such info; AFAICS all the callers of PinBuffer know what they want to happen. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend