Horton

Re: Hash Functions

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Joe Conway <mail@joeconway.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>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2017-08-03T21:50:05Z
Lists: pgsql-hackers 
Hi,

On 2017-08-03 17:43:44 -0400, Robert Haas wrote:
> For me, the basic point here is that we need a set of hash functions
> for hash partitioning that are different than what we use for hash
> indexes and hash joins -- otherwise when we hash partition a table and
> create hash indexes on each partition, those indexes will have nasty
> clustering.  Partitionwise hash joins will have similar problems.  So,
> a new set of hash functions specifically for hash partitioning is
> quite desirable.

Couldn't that just as well solved by being a bit smarter with an IV? I
doubt we want to end up with different hashfunctions for sharding,
partitioning, hashjoins (which seems to form a hierarchy). Having a
working hash-combine function, or even better a hash API that can
continue to use the hash's internal state, seems a more scalable
solution.

Greetings,

Andres Freund

Commits

  1. Introduce 64-bit hash functions with a 64-bit seed.

  2. Create a "sort support" interface API for faster sorting.

  3. Add seven kanji characters defined in the Windows 950 codepage to our