On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > What I think it's necessary for is at least: > > > * Move the buffer content lock inline into to the buffer descriptor, > > while still fitting into one cacheline. > > * lockless/atomic Pin/Unpin Buffer. > > TBH, that argument seems darn weak, not to mention probably applicable > only to current-vintage Intel chips. And you have not proven that > narrowing the backend ID is necessary to either goal, even if we > accepted that these goals were that important. > > While I agree with you that it seems somewhat unlikely we'd ever get > past 2^16 backends, these arguments are not nearly good enough to > justify a hard-wired limitation.
I'm satisfied with the arguments Andres presented, which I presume were weak only because he didn't expect a staunch defense of max_connections=70000 use. The new restriction will still permit settings an order of magnitude larger than current *worst* practice and 2-3 orders of magnitude larger than current good practice. If the next decade sees database server core counts grow by two orders of magnitude or sees typical cache architectures change enough to make the compactness irrelevant, we'll have the usual opportunities to react. Today, the harm from contention on buffer headers totally eclipses the benefit of allowing max_connections=70000. There's no cause to predict a hardware development radical enough to change that conclusion. 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. 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. nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers