On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote: > Simon Riggs wrote: > >>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. > > For 8.1 we should definitely Do The > Right Thing and develop a complete ARC replacement.
Agreed. That would be my focus. > 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. Agree with everything apart from the idea that seq scan flooding isn't an issue. I definitely think it is. -- Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
