On Wed, Feb 22, 2012 at 6:17 PM, Peter Geoghegan <peter@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