Re: why after increase the hash table partitions, tpmc decrease

Поиск
Список
Период
Сортировка
От Takashi Horikawa
Тема Re: why after increase the hash table partitions, tpmc decrease
Дата
Msg-id 73FA3881462C614096F815F75628AFCD01989DA1@BPXM01GP.gisp.nec.co.jp
обсуждение исходный текст
Ответ на why after increase the hash table partitions, tpmc decrease  (Xiaoyulei <xiaoyulei@huawei.com>)
Список pgsql-performance
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@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Xiaoyulei
> Sent: Tuesday, September 02, 2014 4:00 PM
> To: pgsql-performance@postgresql.org
> Cc: yetao
> Subject: [PERFORM] 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
>
>


Вложения

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

Предыдущее
От: Shadin A
Дата:
Сообщение: Implementing a functionality for processing heavy insertion
Следующее
От: gmb
Дата:
Сообщение: Re: Performance issue: index not used on GROUP BY...