Re: So, would it make sense to do something like a CRC on

Поиск
Список
Период
Сортировка
От Dann Corbit
Тема Re: So, would it make sense to do something like a CRC on
Дата
Msg-id 54798A299E68514AB7C4DEBA25F03BE119147E@postal.corporate.connx.com
обсуждение исходный текст
Список 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@postgresql.org
> [mailto:pgsql-general-owner@postgresql.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@candle.pha.pa.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
>

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Memory exhausted (leak?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: incorrect checksum in control file