From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Joel" <rees(at)ddcom(dot)co(dot)jp> |
Cc: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: So, would it make sense to do something like a CRC on |
Date: | 2004-09-10 03:19:28 |
Message-ID: | 54798A299E68514AB7C4DEBA25F03BE119147E@postal.corporate.connx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
UMAC is a 64 bit portable hash that is stupendously fast.
On a 2.2 GHz AMD 64 bit machine, I got 1.2 GB/sec hash data throughput
from a modified version of crypto++.
The code base for Crypto++ is mostly public domain (with one or two
unimportant exceptions that can easily be excluded from the code base).
It could also be used for encrypt/decrypt operations.
Algorithm Megabytes(2^20 bytes) Processed Time Taken
MB/Second
UMAC-64 1.64E+04 13.094 1251.26
Adler-32 8.19E+03 7.094 1154.779
DJB-32 8.19E+03 13.251 618.217
DJBx-32 4.10E+03 6.797 602.619
BJ-32 4.10E+03 7.016 583.808
Panama Hash (little endian) 4.10E+03 7.844 522.183
FNV-32 4.10E+03 7.89 519.138
Panama Hash (big endian) 4.10E+03 8.922 459.09
OY-32 4.10E+03 9.094 450.407
Panama Cipher (little endian) 4.10E+03 9.094 450.407
Panama Cipher (big endian) 4.10E+03 9.579 427.602
CRC-32 4.10E+03 12.501 327.654
SEAL-3.0-BE 4.10E+03 13.282 308.387
SEAL-3.0-LE 2.05E+03 6.844 299.24
WAKE-OFB-LE 2.05E+03 7.485 273.614
HMAC/MD5 2.05E+03 7.719 265.319
MD5 2.05E+03 7.781 263.205
WAKE-OFB-BE 2.05E+03 7.797 262.665
DJB/OY-64 2.05E+03 7.876 260.03
XMACC/MD5 2.05E+03 8.188 250.122
MD5-MAC 2.05E+03 8.641 237.01
WAKE-CFB-LE 2.05E+03 9.297 220.286
WAKE-CFB-BE 2.05E+03 10.235 200.098
SHA-1 2.05E+03 10.891 188.045
HAVAL (pass=3) 1.02E+03 7.641 134.014
BJ-64 1.02E+03 7.688 133.195
HAVAL (pass=4) 1.02E+03 7.938 129
RC6 1.02E+03 8.36 122.488
FNV-64 1.02E+03 8.407 121.803
RIPE-MD160 1.02E+03 8.532 120.019
Two-Track-MAC 1.02E+03 8.703 117.661
HAVAL (pass=5) 1.02E+03 9.656 106.048
RC5 (r=16) 1.02E+03 10.048 101.911
ARC4 1.02E+03 10.891 94.023
SHA-256 1.02E+03 11.438 89.526
MARS 1.02E+03 11.75 87.149
Tiger 1.02E+03 12.063 84.888
Square 1.02E+03 12.345 82.949
> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> Sent: Thursday, September 09, 2004 8:05 PM
> To: Joel
> Cc: Postgres General
> Subject: Re: [GENERAL] So, would it make sense to do
> something like a CRC on
>
>
> Joel wrote:
> > Pardon me for this, but it's Monday morning here and I'm in shallow
> > thinking mode.
> >
> > I was just looking over Wes's questions about checking database
> > integrity, and the responses given, and I'm wondering if keeping a
> > live CRC on each record would make sense? Or is this
> already done, or
> > maybe an option? (Not that it would in any way solve Wes's
> company's
> > current problem, ...)
>
> TODO has:
>
> * Add optional CRC checksum to heap and index pages
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square,
> Pennsylvania 19073
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-10 03:36:52 | Re: incorrect checksum in control file |
Previous Message | Tom Lane | 2004-09-10 03:19:27 | Re: Memory exhausted (leak?) |