Re: Move PinBuffer and UnpinBuffer to atomics - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id CAPpHfdtfr3Aj7xJonXaKR8iY2p8uXOQ+e4BMpMDAM_5R4OcaDA@mail.gmail.com
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics
List pgsql-hackers
On Sun, Mar 27, 2016 at 4:31 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund <andres@anarazel.de> wrote:
On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote:
> On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov <
> a.korotkov@postgrespro.ru> wrote:
>
> > Thank you very much for testing!
> > I also got access to 4 x 18 Intel server with 144 threads. I'm going to
> > post results of tests on this server in next Monday.
> >
>
> I've run pgbench tests on this machine: pgbench -s 1000 -c $clients -j 100
> -M prepared -T 300.
> See results in the table and chart.
>
> clients master  v3      v5
> 1       11671   12507   12679
> 2       24650   26005   25010
> 4       49631   48863   49811
> 8       96790   96441   99946
> 10      121275  119928  124100
> 20      243066  243365  246432
> 30      359616  342241  357310
> 40      431375  415310  441619
> 50      489991  489896  500590
> 60      538057  636473  554069
> 70      588659  714426  738535
> 80      405008  923039  902632
> 90      295443  1181247 1155918
> 100     258695  1323125 1325019
> 110     238842  1393767 1410274
> 120     226018  1432504 1474982
> 130     215102  1465459 1503241
> 140     206415  1470454 1505380
> 150     197850  1475479 1519908
> 160     190935  1420915 1484868
> 170     185835  1438965 1453128
> 180     182519  1416252 1453098
>
> My conclusions are following:
> 1) We don't observe any regression in v5 in comparison to master.
> 2) v5 in most of cases slightly outperforms v3.

What commit did you base these tests on? I guess something recent, after
98a64d0bd?

Yes, more recent than 98a64d0bd. It was based on 676265eb7b.
 
> I'm going to do some code cleanup of v5 in Monday

Ok, I'll try to do a review and possibly commit after that.

Sounds good.

There is next revision of patch.  It contains mostly cosmetic changes.  Comment are adjusted to reflect changes of behaviour.
I also changed atomic AND/OR for local buffers to read/write pair which would be cheaper I suppose.  However, I don't insist on it, and it could be reverted.
The patch is ready for your review.  It's especially interesting what do you think about the way I abstracted exponential back off of spinlock.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 
Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Relation extension scalability
Next
From: Thomas Munro
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data