On Fri, Mar 3, 2017 at 1:22 AM, Andres Freund <and...@anarazel.de> wrote: > the resulting hash-values aren't actually meaningfully influenced by the > IV. Because we just xor with the IV, most hash-value that without the IV > would have fallen into a single hash-bucket, fall into a single > hash-bucket afterwards as well; just somewhere else in the hash-range.
Wow, OK. I had kind of assumed (without looking) that setting the hash IV did something a little more useful than that. Maybe we should do something like struct blah { int iv; int hv; }; newhv = hash_any(&blah, sizeof(blah)). > In addition to that it seems quite worthwhile to provide an iterator > that's not vulnerable to this. An approach that I am, seemingly > successfully, testing is to iterate the hashtable in multiple (in my > case 23, because why not) passes, accessing only every nth element. That > allows the data to be inserted in a lot less "dense" fashion. But > that's more an optimization, so I'll just push something like the patch > mentioned in the thread already. > > Makes some sense? Yep. -- 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