Re: [HACKERS] Hash Functions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [HACKERS] Hash Functions
Date
Msg-id CAMp0ubfCyTXDkkuo75oWUoQfaKqAuvhea_cps=4-EKX_VdW7tQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Hash Functions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Hash Functions  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sun, May 14, 2017 at 8:00 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Do we even know that floats are precise enough to determine the
> partition.  For example, if you have 6.000000001, is it possible for
> that to be 5.9999999 on some systems?  Are IEEE systems all the same for
> these values?  I would say we should disallow any approximate date type
> for partitioning completely.

I'm inclined in this direction, as well. Hash partitioning is mostly
useful for things that are likely to be join keys or group keys, and
floats aren't. Same for complex user-defined types.

The real problem here is what Tom pointed out: that we would have
trouble hashing strings in an encoding-insensitive way. Strings are
useful as join/group keys, so it would be painful to not support them.

Perhaps there's some kind of compromise, like a pg_dump mode that
reloads through the root. Or maybe hash partitions are really a
"semi-logical" partitioning that the optimizer understands, but where
things like per-partition check constraints don't make sense.

Regards,   Jeff Davis


Regards,   Jeff Davis



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Increasing parallel workers at runtime
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression