On Wed, Feb 22, 2012 at 6:17 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > I decided that it would be worth benchmarking this patch. > Specifically, I tested: > > master, as a basis of comparison > > checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on' > > checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'off' > > This test was performed using pgbench-tools. At different client > counts and scaling factors "1,10,100", performance of an update.sql > workload was tested. > > This benchmark used Greg Smith's "toy" server. As he put it recently: > > "The main change to the 8 hyperthreaded core test server (Intel > i7-870) for this year is bumping it from 8GB to 16GB of RAM, which > effectively doubles the scale I can reach before things slow > dramatically." However, while Greg used scientific Linux for his > recent batch of performance numbers, the box was booted into Debian > for this, which used Kernel 2.6.32, FWIW. Didn't bother with a > separate disk for WAL. > > I put shared_buffers at 1GB, and checkpoint_segments at 50. I took the > additional precaution of initdb'ing for each set, lest there be some > kind of contamination between sets, which necessitated doing some > additional work since I couldn't very well expect the "results" > database to persist. Different sets of figures from different runs > where dumped and restored, before finally being combined so that > pgbench-tools could produce it's regular report. > > I have attached a config for pgbench-tools, so that others may > recreate my work here. I also attach the most relevant image, > comparing each test set across scaling levels. I'll make a pdf of the > full report available if that would be useful.
Thanks for testing this. The graph obscures a bit how much percentage change we're talking about here - could you post the raw tps numbers? I think we also need to test the case of seq-scanning a large, unhinted table. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
