Noah Misch <n...@leadboat.com> writes:
> On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
>> 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.
Well, let me clarify my position: I'm not against reducing MAX_BACKENDS
if we get a significant improvement by doing so. But the case for that
has not been made.
>> 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.
We were just a few days ago discussing (again) making changes to the
buffer allocation algorithms. It hardly seems implausible that any
useful improvements there might need new or different fields in the
buffer headers.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
