From: | karavelov(at)mail(dot)bg |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FWD: fastlock+lazyvzid patch performance |
Date: | 2011-06-24 23:49:09 |
Message-ID: | 2c431b5f46cccba1e964f940967a8f33.mailbg@mail.bg |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Цитат от Robert Haas (robertmhaas(at)gmail(dot)com), на 25.06.2011 в 00:16 -----
> On Fri, Jun 24, 2011 at 3:31 PM, 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: ???
9.1beta2 + fastlock patch + vxid patch , pgbench run on unix domain
socket, the other tests are using local TCP connection.
> 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.
>
Yes, it does make some difference,
Using unpatched beta2, 8 clients with simple protocol I get 57059 tps.
With all patches and simple protocol I get 60707 tps. So the difference
between patched/stock is not so big. I suppose the system gets CPU bound
on parsing and planning every submitted request. With -M extended I
get even slower results.
Luben
--
"Perhaps, there is no greater love than that of a
revolutionary couple where each of the two lovers is
ready to abandon the other at any moment if revolution
demands it."
Zizek
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-06-24 23:49:11 | Re: Deriving release notes from git commit messages |
Previous Message | Bruce Momjian | 2011-06-24 23:47:23 | Re: pg_upgrade defaulting to port 25432 |