Hi, > We modify the following macro definition: > NUM_BUFFER_PARTITIONS 1024 > LOG2_NUM_PREDICATELOCK_PARTITIONS 10 > LOG2_NUM_LOCK_PARTITIONS 10 IME, increase in NUM_BUFFER_PARTITIONS is effective but that in LOG2_NUM_LOCK_PARTITIONS results in performance degradation. Probably because it leads to an increase in overhead of LockReleaseAll() in src/backend/storage/lmgr/lock.c. I recommends that LOG2_NUM_LOCK_PARTITIONS should not be increased so much. Best regards, Takashi Horikawa -- > -----Original Message----- > From: pgsql-performance-owner@xxxxxxxxxxxxxx > [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Xiaoyulei > Sent: Tuesday, September 02, 2014 4:00 PM > To: pgsql-performance@xxxxxxxxxxxxxx > Cc: yetao > Subject: why after increase the hash table partitions, tpmc > decrease > > > > We use benchmarksql to start tpcc test in postgresql 9.3.3. > > Before test we set benchmarksql client number about 800. And we increase > the hash partitions from 16 to 1024 , in order to reduce the hash partition > locks competition. > > We expect that after increase the number of partitions, reduces lock > competition, TPMC should be increased. But the test results on the contrary, > after modified to 1024, TPMC did not increase, but decrease. > > Why such result? > > > > We modify the following macro definition: > > NUM_BUFFER_PARTITIONS 1024 > > LOG2_NUM_PREDICATELOCK_PARTITIONS 10 > > LOG2_NUM_LOCK_PARTITIONS 10 > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
