On 2014-04-26 11:52:44 +0100, Greg Stark wrote: > On Fri, Apr 25, 2014 at 11:15 PM, Andres Freund <and...@2ndquadrant.com> > wrote: > > Since there's absolutely no sensible scenario for setting > > max_connections that high, I'd like to change the limit to 2^16, so we > > can use a uint16 in BufferDesc->refcount. > > Clearly there's no sensible way to run 64k backends in the current > architecture.
The current limit is 2^24, I am only proposing to lower it to 2^16. > But I don't think it's beyond the realm of possibility > that we'll reduce the overhead in the future with an eye to being able > to do that. Is it that helpful that it's worth baking in more > dependencies on that limitation? I don't think it's realistic that we'll ever have more than 2^16 full blown backends. We might (I hope!) a builtin pooler, but pooler connections won't be full backends. So I really don't see any practical limitation with limiting the max number of backends to 65k. 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. Imo those are significant scalability advantages... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
