Re: Change GUC hashtable to use simplehash?
От | Heikki Linnakangas |
---|---|
Тема | Re: Change GUC hashtable to use simplehash? |
Дата | |
Msg-id | 2b95985f-c377-4612-840a-9367e9662d5b@iki.fi обсуждение исходный текст |
Ответ на | Re: Change GUC hashtable to use simplehash? (John Naylor <johncnaylorls@gmail.com>) |
Ответы |
Re: Change GUC hashtable to use simplehash?
|
Список | pgsql-hackers |
On 29/11/2023 15:31, John Naylor wrote: > However, I did find a couple hash functions that are much simpler to > adapt to a bytewise interface, pass SMHasher, and are decently fast on > short inputs: > > - fast-hash, MIT licensed, and apparently has some use in software [1] > - MX3, CC0 license (looking around, seems controversial for a code > license, so didn't go further). [2] Seems to be a for-fun project, but > the accompanying articles are very informative on how to develop these > things. > > After wacking fast-hash around, it doesn't really resemble the > original much, and if for some reason we went as far as switching out > the mixing/final functions, it may as well be called completely > original work. I thought it best to start with something whose mixing > behavior passes SMHasher, and hopefully preserve that property. I didn't understand what you meant by the above. Did you wack around fast-hash, or who did? Who switched mixing/final functions; compared to what? The version you have in the patch matches the implementation in smhasher, did you mean that the smhasher author changed it compared to the original? In any case, +1 on the implementation you had in the patch at a quick glance. Let's also replace the partial murmurhash implementations we have in hashfn.h with this. It's a very similar algorithm, and we don't need two. -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: