Robert Haas <robertmh...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
