On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund <and...@anarazel.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.korot...@postgrespro.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. > > 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? > > Spinning on a lock as fast as possible leads to rapid cacheline bouncing > without anybody making progress. See s_lock() in s_lock.c. > I didn't notice that s_lock() behaves so. Thank you. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
