However, I think the ARC replacement should *not* be a fundamental change in behavior: the algorithm should still attempt to balance recency and frequency, to adjust dynamically to changes in workload, to avoid "sequential flooding", and to allow constant-time page replacement.
Agreed: Those are the requirements. It must also scale better as well.
On thinking about this more, I'm not sure these are the right goals for an 8.0.x replacement algorithm. For 8.1 we should definitely Do The Right Thing and develop a complete ARC replacement. For 8.0.x, I wonder if it would be better to just replace ARC with LRU. The primary advantage to doing this is LRU's simplicity -- if we're concerned about introducing regressions in stability into 8.0, this is likely the best way to reduce the chance of that happening. Furthermore, LRU's behavior with PostgreSQL is well-known and has been extensively tested. A complex ARC replacement would receive even less testing than ARC itself has received -- which isn't a whole lot, in comparison with LRU.
Of course, the downside is that we lose the benefits of ARC or an ARC-like algorithm in 8.0. That would be unfortunate, but I don't think it is a catastrophe. The other bufmgr-related changes (vacuum hints, bgwriter and vacuum delay) should ensure that VACUUM still has a much reduced impact on system performance. Sequential scans will still flood the cache, but I don't view that as an enormous problem. In other words, I think a more intelligent replacement policy would be nice to have, but at this point in the 8.0 development cycle we should go with the simplest solution that we know is likely to work -- namely, LRU.
-Neil
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
