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  (David Fetter <david@fetter.org>)
Re: Decrease MAX_BACKENDS to 2^16  (Andres Freund <andres@2ndquadrant.com>)
Re: Decrease MAX_BACKENDS to 2^16  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problem with displaying "wide" tables in psql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Decrease MAX_BACKENDS to 2^16