Skip site navigation (1) Skip section navigation (2)

Re: 16-bit page checksums for 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, david(at)fetter(dot)org, aidan(at)highrise(dot)ca, stark(at)mit(dot)edu
Subject: Re: 16-bit page checksums for 9.2
Date: 2012-02-23 01:39:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 22, 2012 at 6:17 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Daniel FarinaDate: 2012-02-23 04:17:08
Subject: Re: Should we add crc32 in libpgport?
Previous:From: Robert HaasDate: 2012-02-23 01:36:08
Subject: Re: Displaying accumulated autovacuum cost

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group