On Sat, Apr 26, 2014 at 1:30 PM, Noah Misch <n...@leadboat.com> wrote: > Sure, let's not actually commit a patch to impose this limit until the first > change benefiting from doing so is ready to go. There remains an opportunity > to evaluate whether that beneficiary change is better done a different way. > By having this thread to first settle that the new max_connections limit is > essentially okay, the eventual thread concerning lock-free pin manipulation > need not inflate from discussion of this side issue.
I agree with your remarks here. This kind of thing is only going to become more important. > On Sat, Apr 26, 2014 at 11:22:39AM -0400, Tom Lane wrote: >> And next week when we need some other field in a buffer header, >> what's going to happen? If things are so tight that we need to >> shave a few bits off backend IDs, the whole thing is a house of >> cards anyway. > > The buffer header has seen one change in nine years. Making it an inviting > site for future patches is not important. My prototype caching patch, which seems promising to me adds an instr_time to the BufferDesc struct. While that's obviously something that isn't acceptable, and while I obviously could do better, it still strikes me that that is the natural place to put such a piece of state. That doesn't mean it's the best place, but it's still a point worth noting in the context of this discussion. As I mention on the thread concerning that work, the LRU-K paper recommends a time-based delay throttling incrementation of usage_count to address the problem of "correlated references" (5 seconds is suggested there). At least one other major system implements a configurable delay defaulting to 3 seconds. The 2Q paper also suggests a correlated reference period. -- 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