Re: Decrease MAX_BACKENDS to 2^16
От | Tom Lane |
---|---|
Тема | Re: Decrease MAX_BACKENDS to 2^16 |
Дата | |
Msg-id | 21785.1398525656@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Decrease MAX_BACKENDS to 2^16 (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Decrease MAX_BACKENDS to 2^16
Re: Decrease MAX_BACKENDS to 2^16 Re: Decrease MAX_BACKENDS to 2^16 |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-04-26 11:52:44 +0100, Greg Stark wrote: >> 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? > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: