On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote:
> On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > >> >> On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar <dilipbal...@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 >
pinunpin-cas-2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
