Re: Thoughts about NUM_BUFFER_PARTITIONS

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Thoughts about NUM_BUFFER_PARTITIONS
Дата
Msg-id a1444b5b-3e8f-44ca-8834-6d99183522f8@iki.fi
обсуждение исходный текст
Ответ на Thoughts about NUM_BUFFER_PARTITIONS  (wenhui qiu <qiuwenhuifx@gmail.com>)
Ответы Re: Thoughts about NUM_BUFFER_PARTITIONS
Список pgsql-hackers
On 08/02/2024 12:17, wenhui qiu wrote:
> HI hackers
>      When I read this text in this document there is a paragraph in 
> it(https://www.interdb.jp/pg/pgsql08/03.html 
> <https://www.interdb.jp/pg/pgsql08/03.html>)
> /*
> The BufMappingLock is split into partitions to reduce contention in the 
> buffer table (the default is 128 partitions). Each BufMappingLock 
> partition guards a portion of the corresponding hash bucket slots.
> */,
> 
> Physical servers with terabytes of RAM are now commonplace,I'm looking 
> at the comments inside the source code.I'm looking at the comments 
> inside the source code to see if they still match the current hardware 
> capability?

The optimal number of partitions has more to do with the number of 
concurrent processes using the buffer cache, rather than the size of the 
cache. The number of CPUs in servers has increased too, but not as much 
as RAM.

But yeah, it's a valid question if the settings still make sense with 
modern hardware.

> The  comment says that in the future there may be a 
> parameter,Iam a  dba now and I try to think of implementing this 
> parameter, but I'm not a professional kernel developer, I still want the 
> community senior developer to implement this parameter

The first thing to do would be to benchmark with different 
NUM_BUFFER_PARTITIONS settings, and see if there's benefit in having 
more partitions.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Refactoring backend fork+exec code
Следующее
От: Mats Kindahl
Дата:
Сообщение: Re: glibc qsort() vulnerability