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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Move PinBuffer and UnpinBuffer to atomics  (Andres Freund <andres@anarazel.de>)
Список 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    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

Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Copy-pasto in the ExecForeignDelete documentation