From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Xiaoyulei <xiaoyulei(at)huawei(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why after increase the hash table partitions, TPMC decrease |
Date: | 2014-09-02 11:30:50 |
Message-ID: | CAA4eK1KDTCNsfq=wJTgPb3aJGj-k7SyxwT9jyvPR5P-wQoY3MA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 2, 2014 at 2:09 PM, Xiaoyulei <xiaoyulei(at)huawei(dot)com> wrote:
>
>
>
> 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.
I think you can expect some increase mainly if your test is
read only and you have sufficient RAM such that it can contain
all the data, for other cases there can be I/O due to which you
might not see any increase.
> 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
Increasing these numbers might lead to error
"too many LWLocks taken", unless you increase
MAX_SIMUL_LWLOCKS. Once you can check the server
log if it contains any errors, that might lead to decrease in
performance.
Also another side effect would be that increasing above numbers
will lead to increase in shared memory usage.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Xiaoyulei | 2014-09-02 11:50:42 | 答复: [HACKERS] why after increase the hash table partitions, TPMC decrease |
Previous Message | Heikki Linnakangas | 2014-09-02 11:26:51 | Re: pgsql: Compress GIN posting lists, for smaller index size. |