On Tue, Apr 14, 2015 at 7:02 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Apr 14, 2015 at 6:22 PM, Peter Geoghegan <p...@heroku.com> wrote: >> Why is that good? > > We did discuss this before. I've recapped some of what I believe to > be the most salient points below. > >> I think that people were all too quick to dismiss the idea of a wall >> time interval playing some role here (at least as a defense against >> correlated references, as a correlated reference period). I suppose >> that that's because it doesn't fit with an intuition that says that >> that kind of interval ought to be derived algebraically - magic delay >> settings are considered suspect. > > Yep, Tom gave that reason here: > > http://www.postgresql.org/message-id/11258.1397673...@sss.pgh.pa.us > > But there was also this point from Andres - gettimeofday is not free: > > http://www.postgresql.org/message-id/20140416075307.gc3...@awork2.anarazel.de > > And this point from me - this can degrade to random eviction under > high pressure: > > http://www.postgresql.org/message-id/ca+tgmoayuxr55zueapp6d2xbyicjwacc9myyn5at4tindsj...@mail.gmail.com > > You'll notice that my proposal avoids all three of those objections.
All I'm saying is that you shouldn't dismiss the idea without trying it out properly. The LRU-K paper, from the early 1990s, recommends this, and gettimeofday() calls were a lot more expensive back then. I'm sure that there is a way to overcome these issues if it turns out to be worth it (by amortizing gettimeofday() calls by driving it from an auxiliary process like the bgwriter, for example). In fact, I'm almost certain there is, because at least one other major database system uses just such a reference period. Back when ARC (or was it 2Q?) was committed before being reverted shortly thereafter, there was a similar idea actually implemented, but with XIDs preventing correlated references (which the LRU-K paper also hints at). I think that an actual delay is more robust than that, though. Even though this correlated reference delay is all I implemented with my prototype,it's just one piece of the puzzle. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers