On Sat, Apr 26, 2014 at 1:30 PM, Noah Misch <noah@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