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. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
config
Description: Binary data
<<attachment: scaling-sets-page-checksums.png>>
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
