Re: Hash Functions
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Jeff Davis <pgsql@j-davis.com>, Yugo Nagata <nagata@sraoss.co.jp>, amul sul <sulamul@gmail.com>
Date: 2017-05-13T14:29:09Z
Lists: pgsql-hackers
On Sat, May 13, 2017 at 12:52 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > Can we think of defining separate portable hash functions which can be > used for the purpose of hash partitioning? I think that would be a good idea. I think it shouldn't even be that hard. By data type: - Integers. We'd need to make sure that we get the same results for the same value on big-endian and little-endian hardware, and that performance is good on both systems. That seems doable. - Floats. There may be different representations in use on different hardware, which could be a problem. Tom didn't answer my question about whether any even-vaguely-modern hardware is still using non-IEEE floats, which I suspect means that the answer is "no". If every bit of hardware we are likely to find uses basically the same representation of the same float value, then this shouldn't be hard. (Also, even if this turns out to be hard for floats, using a float as a partitioning key would be a surprising choice because the default output representation isn't even unambiguous; you need extra_float_digits for that.) - Strings. There's basically only one representation for a string. If we assume that the hash code only needs to be portable across hardware and not across encodings, a position for which I already argued upthread, then I think this should be manageable. - Everything Else. Basically, everything else is just a composite of that stuff, I think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 landed
-
Create a "sort support" interface API for faster sorting.
- c6e3ac11b60a 9.2.0 cited
-
Add seven kanji characters defined in the Windows 950 codepage to our
- 2dbbf33f4a95 8.4.0 cited