On Tue, May 8, 2018 at 10:22 AM, Юрий Соколов <funny.fal...@gmail.com> wrote: > "just prior to the point" means we have to have machinery for information > expiration without eviction. For example, same "clock hand" should walk > over all buffers continiously, and decrement "usage count", but without > eviction performed. Right?
Right. > As alternative, some approximation of Working Set algorithm could be used: > - on every access "access time" should be written to item, > - items accessed before some "expiration interval" are considered for > expiration. > This way, there is also fresh information about usage even without any > expiration performed yet. That's basically the same kind of thing. Ideally we want to have one mechanism that operates all the time, rather than one that works when no eviction is occurring and a completely separate one that operates when eviction is occurring. Anyway, I think we really ought to investigate CAR. CAR could be made to piggyback on our existing GLOCK scheme. See section III.B of the the CAR paper, page 4, especially the second paragraph in the second column. What would change is that instead of sweeping through all buffers, there would be two sets of buffers T1 and T2, each with a separate clock hand. Also, we'd need to store the history lists B1 and B2 someplace. Independently of that, it would be probably also useful to avoid bumping the reference count multiple times when a buffer is accessed by the same backend several times in quick succession. Perhaps this could even be as simple as maintaining a list of the last two buffer IDs for which we bumped the usage count; if we see one of them again, don't bump the usage count again. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
