Robert Haas <robertmhaas@gmail.com> wrote:
>> There's no reason that the hash value of an integer of the same
>> size as the hash shouldn't be the integer itself, for example.
>> It's hard to get more predictable than that, yet it works well
>> for hash lookups.
>
> Well, no, not really. For example, it may be that you have a hash
> table with N buckets and values that of the form N+k, 2N+k, 3N+k,
> .... and everything will collide.
That hardly seems convincing if the integer is a sequentially
assigned number, as with many ID columns; but if you want an
algorithm which will work well with numbers which might be assigned
in a pattern with a high correlation with some unpredictable number
of buckets -- sure, it won't work well without some scrambling. For
sequentially assigned numbers, that scrambling would have a cost and
would be of no value. I guess it depend a bit on your use case and
goals.
-Kevin