Re: Hash Functions
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Stark <stark@mit.edu>, Amit Kapila <amit.kapila16@gmail.com>, "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-15T01:35:45Z
Lists: pgsql-hackers
Hi, On 2017-05-14 21:22:58 -0400, Robert Haas wrote: > but wanting a CHECK constraint that applies to only one partition > seems pretty reasonable (e.g. CHECK that records for older years are > all in the 'inactive' state, or whatever). On a hash-partitioned table? > Now that's not to say that we shouldn't have a > reload-through-the-top-parent switch; actually, I think that's a good > idea. I just don't believe that it can ever be a complete substitute > for portable hash functions. I think almost everybody here agrees > that it isn't necessary to have hash functions that are 100% portable, > e.g. to VAX. But it would be nice IMHO if you could use an integer > column as the partitioning key and have that be portable between Intel > and POWER. I'm not saying it can't work for any datatype, I just think it'd be a very bad idea to make it work for any non-trivial ones. The likelihood of reguarly breaking or preventing us from improving things seems high. I'm not sure that having a design where this most of the time works for some datatypes is a good one. Greetings, Andres Freund
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