From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Ildar Musin <i(dot)musin(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: General purpose hashing func in pgbench |
Date: | 2017-12-25 14:12:19 |
Message-ID: | alpine.DEB.2.20.1712251506160.22976@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
>> I noticed from the source of all human knowledege (aka Wikipedia:-)
>> that there seems to be a murmur3 successor. Have you considered it?
>> One good reason to skip it would be that the implementation is long
>> and complex. I'm not sure about a 8-byte input simplified version.
> Murmur2 naturally supports 8-byte data. Murmur3 has 32- and 128-bit
> versions.
Ok.
So it would make sense to keep the 64 bit murmur2 version.
Pgbench ints are 64 bits, seems logical to keep them that way, so 32 bits
versions do not look too interesting.
>> Just a question: Have you looked at SipHash24?
>
> Not yet. As I can understand from the wiki its main feature is to
> prevent attacks with crafted input data. How can it be useful in
> benchmarking?
No and yes:-)
The attack prevention is pretty useless in the context.
However, the key can be used if controlled so that different values do not
have the same randomization in different part of the script, so as to
avoid using the same patterns for different things if not desirable.
For the pgbench pseudo-random permutation I'm looking at, the key can be
specified to control whether the same pattern or not should be used.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksandr Parfenov | 2017-12-25 14:15:07 | Re: [HACKERS] Flexible configuration for full-text search |
Previous Message | Ildar Musin | 2017-12-25 13:24:38 | Re: General purpose hashing func in pgbench |