Re: Move PinBuffer and UnpinBuffer to atomics
| От | Alexander Korotkov |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | CAPpHfdu77FUi5eiNb+jRPFh5S+1U+8ax4Zw=AUYgt+CPsKiyWw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
| Ответы |
Re: Move PinBuffer and UnpinBuffer to atomics
Re: Move PinBuffer and UnpinBuffer to atomics |
| Список | pgsql-hackers |
On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:By looking at the results with scale factor 1000 and 100 i don't see any reason why it will regress with scale factor 300.So I will run the test again with scale factor 300 and this time i am planning to run 2 cases.
1. when data fits in shared buffer
2. when data doesn't fit in shared buffer.I have run the test again with 300 S.F and found no regression, in fact there is improvement with the patch like we saw with 1000 scale factor.
Shared Buffer= 8GB
max_connections=150
Scale Factor=300
./pgbench -j$ -c$ -T300 -M prepared -S postgres
Client Base Patch
1 19744 19382
8 125923 126395
32 313931 333351
64 387339 496830
128 306412 350610
Shared Buffer= 512MB
max_connections=150
Scale Factor=300
./pgbench -j$ -c$ -T300 -M prepared -S postgres
Client Base Patch
1 17169 16454
8 108547 105559
32 241619 262818
64 206868 233606
128 137084 217013Great, thanks!
Attached patch is rebased and have better comments.
Also, there is one comment which survive since original version by Andres.
/* Add exponential backoff? Should seldomly be contended tho. */
Andres, did you mean we should twice the delay with each unsuccessful try to lock?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: