On Fri, May 12, 2017 at 12:08 AM, Jeff Davis <pg...@j-davis.com> wrote: > 1. The hash functions as they exist today aren't portable -- they can > return different results on different machines. That means using these > functions for hash partitioning would yield different contents for the > same partition on different architectures (and that's bad, considering > they are logical partitions and not some internal detail).
Hmm, yeah, that is bad. > We could revert 26043592 (copied Tom because that was his patch) to > make hash_any() go back to being portable -- do we know what that > speedup actually was? Maybe the benefit is smaller on newer > processors? Another option is to try to do some combination of > byteswapping and word-at-a-time, which might be better than > byte-at-a-time if the byteswapping is done with a native instruction. With regard to portability, I find that in 2009, according to Tom, we had "already agreed" that it was dispensible: http://postgr.es/m/23832.1234214...@sss.pgh.pa.us I was not able to find where that was agreed. On performance, I found this: https://www.postgresql.org/message-id/20081104202655.gp18...@it.is.rice.edu It says at the end: "The average time to reindex the table using our current hash_any() without the separate mix()/final() was 1696ms and 1482ms with the separate mix()/final() stages giving almost 13% better performance for this stupid metric." > 5. For salts[2], I don't think it's too hard to support them in an > optional way. We just allow the function to be a two-argument function > with a default. Places that care about specifying the salt may do so > if the function has pronargs==2, otherwise it just gets the default > value. If we have salts, I don't think having 64-bit hashes is very > important. If we run out of bits, we can just salt the hash function > differently and get more hash bits. This is not urgent and I believe > we should just implement salts when and if some algorithm needs them. The potential problem with that is that the extra argument might slow down the hash functions enough to matter. Argument unpacking is not free, and the hashing logic itself will get more complex. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
