MIME-Version: 1.0
From: wenhui qiu <qiuwenhuifx@gmail.com>
Date: Thu, 8 Feb 2024 18:17:36 +0800
Message-ID: <CAGjGUAKk7tkw2en37EwPkXk1guLe=bLsrMizW-5LMLtH+12dwA@mail.gmail.com>
Subject: Thoughts about NUM_BUFFER_PARTITIONS
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000007814950610dc1f50"
Archived-At: <https://www.postgresql.org/message-id/CAGjGUAKk7tkw2en37EwPkXk1guLe%3DbLsrMizW-5LMLtH%2B12dwA%40mail.gmail.com>
Precedence: bulk

--0000000000007814950610dc1f50
Content-Type: text/plain; charset="UTF-8"

HI hackers
    When I read this text in this document there is a paragraph in it(
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
 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

/*
 * It's a bit odd to declare NUM_BUFFER_PARTITIONS and NUM_LOCK_PARTITIONS
 * here, but we need them to figure out offsets within MainLWLockArray, and
 * having this file include lock.h or bufmgr.h would be backwards.
 */

/* Number of partitions of the shared buffer mapping hashtable */
#define NUM_BUFFER_PARTITIONS  128

/*
 * The number of partitions for locking purposes.  This is set to match
 * NUM_BUFFER_PARTITIONS for now, on the basis that whatever's good enough
for
 * the buffer pool must be good enough for any other purpose.  This could
 * become a runtime parameter in future.
 */
#define DSHASH_NUM_PARTITIONS_LOG2 7
#define DSHASH_NUM_PARTITIONS (1 << DSHASH_NUM_PARTITIONS_LOG2)

--0000000000007814950610dc1f50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI hackers <br>=C2=A0 =C2=A0 When I read this text in this=
 document there is a paragraph in it(<a href=3D"https://www.interdb.jp/pg/p=
gsql08/03.html">https://www.interdb.jp/pg/pgsql08/03.html</a>)<br>/*<br>The=
 BufMappingLock is split into partitions to reduce contention in the buffer=
 table (the default is 128 partitions). Each BufMappingLock partition guard=
s a portion of the corresponding hash bucket slots.<br>*/,<br><br>Physical =
servers with terabytes of RAM are now commonplace,I&#39;m looking at the co=
mments inside the source code.I&#39;m looking at the comments inside the so=
urce code to see if they still match the current hardware capability? The =
=C2=A0comment says that in the future there may be a parameter,Iam a =C2=A0=
dba now and I try to think of implementing this parameter, but I&#39;m not =
a professional kernel developer, I still want the community senior develope=
r to implement this parameter<br><br>/*<br>=C2=A0* It&#39;s a bit odd to de=
clare NUM_BUFFER_PARTITIONS and NUM_LOCK_PARTITIONS<br>=C2=A0* here, but we=
 need them to figure out offsets within MainLWLockArray, and<br>=C2=A0* hav=
ing this file include lock.h or bufmgr.h would be backwards.<br>=C2=A0*/<br=
><br>/* Number of partitions of the shared buffer mapping hashtable */<br>#=
define NUM_BUFFER_PARTITIONS =C2=A0128<br><br>/*<br>=C2=A0* The number of p=
artitions for locking purposes.=C2=A0 This is set to match<br>=C2=A0* NUM_B=
UFFER_PARTITIONS for now, on the basis that whatever&#39;s good enough for<=
br>=C2=A0* the buffer pool must be good enough for any other purpose.=C2=A0=
 This could<br>=C2=A0* become a runtime parameter in future.<br>=C2=A0*/<br=
>#define DSHASH_NUM_PARTITIONS_LOG2 7<br>#define DSHASH_NUM_PARTITIONS (1 &=
lt;&lt; DSHASH_NUM_PARTITIONS_LOG2)<br><div><span class=3D"gmail-text-only"=
 style=3D"white-space:pre"><br></span></div></div>

--0000000000007814950610dc1f50--