| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enabling Checksums |
| Date: | 2013-03-20 00:17:12 |
| Message-ID: | CA+U5nMJmYF2UzBfX2SC9+TG_69zgfxd5mD6krYcqJOHpH+f0Ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20 March 2013 00:03, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Simon suggested the other day that we should make the
> exact checksum mechanism used pluggable at initdb time, just some last
> minute alternatives checking on the performance of the real server code.
> I've now got the WAL CRC32, the zlib CRC32, and the Intel-derived versions
> Ants hacked on to compare.
Selectable, not pluggable.
I think the safe option is to calculate WAL CRC32, take the lowest 16
bits and use that.
We know that will work, has reasonable distribution characteristics
and might even speed things up rather than have two versions of CRC in
the CPU cache. It also gives us just one set of code to tune to cover
both.
I'd rather get this committed with a safe option and then y'all can
discuss the fine merits of each algorithm at leisure.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2013-03-20 00:54:14 | Re: Enabling Checksums |
| Previous Message | Ants Aasma | 2013-03-20 00:11:13 | Re: Enabling Checksums |