From: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LWLocks in DSM memory |
Date: | 2016-08-19 10:59:00 |
Message-ID: | CAD__OujBo=E9MXt5GaJe9asb5xM0rL=K4xs83GyeZH=m1N0X8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 17, 2016 at 9:12 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >Yes. I want a long wait list, modified in bulk - which should be the
> >case with the above.
>
I ran some pgbench. And, I do not see much difference in performance, small
variance in perf can be attributed to variance in probability of drawing
the particular built-in script.
Server configuration:
./postgres -c shared_buffers=8GB -N 200 -c
min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c
maintenance_work_mem=1GB -c checkpoint_completion_target=0.9 &
pgbench configuration: initialized with scale_factor 300
./pgbench -c $threads -j $threads -T 1800 -M prepared -b simple-update(at)1
-b select-only(at)20 postgres
Simple-update : select-only = 5:95
*cilents* *8* *64* *128*
*Current Code* 38279.663784 258196.067342 283150.495921
*After Patch revert* 37316.09022 268285.506338 280077.913954
*% diff * -2.5171944284 3.9076656356 -1.0851409449
Simple-update : selec-only = 20:80
*cilents* *8* *64* *128*
*Current Code* 23169.021469 134791.996882 154057.101004
*After Patch revert* 23892.91539 135091.645551 150402.80543
%diff 3.1244043775 0.2223044958 -2.3720396854
And this was done on our 8 socket intel machine machine
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-08-19 11:14:43 | Re: LWLocks in DSM memory |
Previous Message | Aleksander Alekseev | 2016-08-19 09:50:30 | Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) |