Re: Decrease MAX_BACKENDS to 2^16
От | Andres Freund |
---|---|
Тема | Re: Decrease MAX_BACKENDS to 2^16 |
Дата | |
Msg-id | 20140426131522.GD13906@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Decrease MAX_BACKENDS to 2^16 (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Decrease MAX_BACKENDS to 2^16
|
Список | pgsql-hackers |
On 2014-04-26 11:52:44 +0100, Greg Stark wrote: > On Fri, Apr 25, 2014 at 11:15 PM, Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: