Re: [HACKERS] Hash Functions
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Hash Functions |
Дата | |
Msg-id | 25549.1494610492@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Hash Functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Hash Functions
Re: [HACKERS] Hash Functions |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, May 12, 2017 at 1:12 PM, Andres Freund <andres@anarazel.de> wrote: >> Given that a lot of data types have a architecture dependent representation, it seems somewhat unrealistic and expensiveto have a hard rule to keep them architecture agnostic. And if that's not guaranteed, then I'm doubtful it makessense as a soft rule either. > That's a good point, but the flip side is that, if we don't have such > a rule, a pg_dump of a hash-partitioned table on one architecture > might fail to restore on another architecture. Today, I believe that, > while the actual database cluster is architecture-dependent, a pg_dump > is architecture-independent. Is it OK to lose that property? I'd vote that it's not, which means that this whole approach to hash partitioning is unworkable. I agree with Andres that demanding hash functions produce architecture-independent values will not fly. Maintaining such a property for float8 (and the types that depend on it) might be possible if you believe that nobody ever uses anything but IEEE floats, but we've never allowed that as a hard assumption before. Even architecture dependence isn't the whole scope of the problem. Consider for example dumping a LATIN1-encoded database and trying to reload it into a UTF8-encoded database. People will certainly expect that to be possible, and do you want to guarantee that the hash of a text value is encoding-independent? regards, tom lane
В списке pgsql-hackers по дате отправления: