Re: Move PinBuffer and UnpinBuffer to atomics

On Sat, Feb 27, 2016 at 2:44 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-02-02 13:12:50 +0300, Alexander Korotkov wrote:
> > On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >
> > > On 2016-02-01 13:06:57 +0300, Alexander Korotkov wrote:
> > > > On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <
> > > > a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > > > >> 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
> > >
> > > So, there's a small regression on low client counts. That's worth
> > > addressing.
> > >
> >
> > Interesting. I'll try to reproduce it.
>
> Any progress here?
>

I didn't reproduce the regression. I had access to multicore machine but
didn't see either regression on low clients or improvements on high clients.
In the attached path spinlock delay was exposed in s_lock.h and used
in LockBufHdr().
Dilip, could you try this version of patch? Could you also run perf or
other profiler in the case of regression. It would be nice to compare
profiles with and without patch. We probably could find the cause of
regression.

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