From: | Takashi Horikawa <t-horikawa(at)aj(dot)jp(dot)nec(dot)com> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: why after increase the hash table partitions, tpmc decrease |
Date: | 2014-09-03 00:12:52 |
Message-ID: | 73FA3881462C614096F815F75628AFCD01989DA1@BPXM01GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)postgresql(dot)org
> [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Xiaoyulei
> Sent: Tuesday, September 02, 2014 4:00 PM
> To: pgsql-performance(at)postgresql(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | gmb | 2014-09-03 19:50:26 | Re: Performance issue: index not used on GROUP BY... |
Previous Message | Shadin A | 2014-09-02 14:44:13 | Implementing a functionality for processing heavy insertion |