| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, amul sul <sulamul(at)gmail(dot)com> |
| Subject: | Re: Hash Functions |
| Date: | 2017-05-15 14:32:30 |
| Message-ID: | CAMp0ubfCyTXDkkuo75oWUoQfaKqAuvhea_cps=4-EKX_VdW7tQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, May 14, 2017 at 8:00 PM, Bruce Momjian <bruce(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-05-15 14:34:02 | Re: Concurrent ALTER SEQUENCE RESTART Regression |
| Previous Message | Dilip Kumar | 2017-05-15 14:21:59 | Re: Increasing parallel workers at runtime |