On 13.06.22 20:20, Robert Haas wrote:
> If the user wants 16-bit checksums, the feature we've already got
> seems good enough -- and, as you say, it doesn't use any extra disk
> space. This proposal is just about making people happy if they want a
> bigger checksum.
It's hard to get any definite information about what size of checksum is
"good enough", since after all it depends on what kinds of errors you
expect and what kinds of probabilities you want to accept. But the best
I could gather so far is that 16-bit CRC are good until about 16 kB
block size.
Which leads to the question whether there is really a lot of interest in
catering to larger block sizes. The recent thread about performance
impact of different block sizes might renew interest in this. But
unless we really want to encourage playing with the block sizes (and if
my claim above is correct), then a larger checksum size might not be needed.
> On the topic of which algorithm to use, I'd be inclined to think that
> it is going to be more useful to offer checksums that are 64 bits or
> more, since IMHO 32 is not all that much more than 16, and I still
> think there are going to be alignment issues. Beyond that I don't have
> anything against your specific suggestions, but I'd like to hear what
> other people think.
Again, gathering some vague information ...
The benefits of doubling the checksum size are exponential rather than
linear, so there is no significant benefit of using a 64-bit checksum
over a 32-bit one, for supported block sizes (current max is 32 kB).