| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | karavelov(at)mail(dot)bg |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: FWD: fastlock+lazyvzid patch performance |
| Date: | 2011-06-24 21:16:48 |
| Message-ID: | BANLkTin=uQNrW3JXoAKnpwsRd9kufKpTvg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 24, 2011 at 3:31 PM, <karavelov(at)mail(dot)bg> wrote:
> clients beta2 +fastlock +lazyvzid local socket
> 8 76064 92430 92198 106734
> 16 64254 90788 90698 105097
> 32 56629 88189 88269 101202
> 64 51124 84354 84639 96362
> 128 45455 79361 79724 90625
> 256 40370 71904 72737 82434
I'm having trouble interpreting this table.
Column 1: # of clients
Column 2: TPS using 9.1beta2 unpatched
Column 3: TPS using 9.1beta2 + fastlock patch
Column 4: TPS using 9.1beta2 + fastlock patch + vxid patch
Column 5: ???
At any rate, that is a big improvement on a system with only 8 cores.
I would have thought you would have needed ~16 cores to get that much
speedup. I wonder if the -M prepared makes a difference ... I wasn't
using that option.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2011-06-24 21:28:23 | Re: ALTER TABLE lock strength reduction patch is unsafe |
| Previous Message | Steve Singer | 2011-06-24 21:14:39 | Re: libpq SSL with non-blocking sockets |