Re: Move PinBuffer and UnpinBuffer to atomics

On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:

> On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
>>
>> On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)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 217013
>>
>
> Great, 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

>