Horton

Re: Hash Functions

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org,Robert Haas <robertmhaas@gmail.com>,Jeff Davis <pgsql@j-davis.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,Yugo Nagata <nagata@sraoss.co.jp>,amul sul <sulamul@gmail.com>,Tom Lane <tgl@sss.pgh.pa.us>
Date: 2017-05-12T17:12:34Z
Lists: pgsql-hackers 

On May 12, 2017 10:05:56 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote:
>On Fri, May 12, 2017 at 12:08 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>> 1. The hash functions as they exist today aren't portable -- they can
>> return different results on different machines. That means using
>these
>> functions for hash partitioning would yield different contents for
>the
>> same partition on different architectures (and that's bad,
>considering
>> they are logical partitions and not some internal detail).
>
>Hmm, yeah, that is bad.

Given that a lot of data types have a architecture dependent representation, it seems somewhat unrealistic and expensive to have a hard rule to keep them architecture agnostic.   And if that's not guaranteed, then I'm doubtful it makes sense as a soft rule either.

Andres

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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