"k...@rice.edu" <k...@rice.edu> writes: > If we are going to consider changing the hash function, we should > consider something like xxhash which runs at 13.8GB/s on a 2.7GHz > x86_64 for the XXH64 variant and 6.8GB/s for the XXH32 variant which > is double the speed of fast-hash according to the page running on a > 3GHz x86_64.
Well, as the google page points out, raw speed is not the only figure of merit; otherwise we'd just xor all the bytes and call it good. We need the hash function to spread out the hash values well, or else we lose more cycles chasing inordinately-long hash chains than we saved with a cheap hash function. Google claims their fast-hash is actually better on this point than Jenkins, which if true would be very nice indeed. Keep in mind also that very very few of our hash keys are longer than about 20 bytes, so that speed-per-byte is not that exciting anyway. Longer setup/finish times could easily swamp any per-byte advantages, for example. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers