On Wed, Jul 27, 2011 at 2:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> The reason the benefit is smaller is, I believe, because the previous
> numbers were generated with the lazy vxid locks patch applied, and
> these were generated against master. With the lock manager as a
> bottleneck, the sinval stuff doesn't get hit quite as hard, so the
> benefit is less. I can regenerate the numbers with the lazy vxid
> patch applied; I suspect they'll be similar to what we saw before.
Yep. Here's with both lazy-vxids and sinval-hasmessages;
01 tps = 4470.133776 (including connections establishing)
01 tps = 4471.450650 (including connections establishing)
01 tps = 4490.833194 (including connections establishing)
32 tps = 191416.960956 (including connections establishing)
32 tps = 190653.742400 (including connections establishing)
32 tps = 191832.231458 (including connections establishing)
80 tps = 189348.509378 (including connections establishing)
80 tps = 191080.641878 (including connections establishing)
80 tps = 191366.728275 (including connections establishing)
And with just lazy vxids:
01 tps = 4458.667013 (including connections establishing)
01 tps = 4526.922638 (including connections establishing)
01 tps = 4480.415099 (including connections establishing)
32 tps = 193273.434028 (including connections establishing)
32 tps = 190661.279391 (including connections establishing)
32 tps = 189526.560031 (including connections establishing)
80 tps = 150572.020250 (including connections establishing)
80 tps = 118643.970622 (including connections establishing)
80 tps = 119211.643930 (including connections establishing)
Same select-only, scale-factor-100 pgbench test, same 32 core machine,
as I've been using for my other recent tests.
> I'll also test out creating and dropping some tables.
Still need to work on this one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
