Re: BUG #17746: Partitioning by hash of a text depends on icu version when text collation is not deterministic
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #17746: Partitioning by hash of a text depends on icu version when text collation is not deterministic |
| Дата | |
| Msg-id | 530248.1673458746@sss.pgh.pa.us обсуждение |
| Ответ на | BUG #17746: Partitioning by hash of a text depends on icu version when text collation is not deterministic (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes:
> What bothers me is that partitioning depends on the hash that can be
> computed differently with the OS upgrade/migration.
There's basically no way to avoid such problems with a non-deterministic
collation. The hash function is required to compute the same hash for
all values that compare equal, and that set can change if the collation
does. Even if the collation hasn't changed in any user-visible way,
what we are hashing for such cases is the result of ucol_getSortKey(),
and the new collation version might well produce a different answer.
Personally, I think hash partitioning is an anti-pattern that ought
to come with bright red warning flags in the docs. If you think you
want it, you're generally wrong, for a number of reasons beyond this.
(Admittedly, range partitioning can also get broken by collation
updates, but at least that doesn't happen without user-visible
behavioral changes in the collation.)
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера