Хэширование столбца составного типа в PostgreSQL эквивалентно по производительности хэшированию нескольких столбцов?

Question

У меня есть вопрос о производительности хеширования составного столбца в Postgres. Итог: производительность идентична производительности хеширования нескольких столбцов, которые имеют тот же тип и расположение, что и атрибуты составного типа?

Позвольте мне привести конкретную ситуацию: Мне дают квартальные дампы базы данных, которые я собираюсь повторно импортировать в Postgres и анализировать. Я не могу контролировать формат предоставленных данных.

В нескольких местах используются первичные ключи, состоящие из шестнадцатеричных кодов длиной 32 символа. Это просто 128-битные целые числа.

Я смоделировал эти первичные ключи в Postgres, используя составной тип (bigint, bigint), и предоставил неявные CASTS для текста от и до.

Однако меня беспокоит производительность. Есть ли потеря производительности?

Answer 1

128-битный ключ не имеет смысла для меня. Сколько ключевых значений действительно допустимо (в любое время)? Вторая проблема может заключаться в том, что 128-битные штуковины являются более или менее случайными, и «последовательные» строки будут перемещаться туда-сюда в пространстве ключей (что приведет к плохой кластеризации записей). Другим аспектом этого будет то, что, учитывая первые 64 бита ключа, второй 64-бит будет практически функционально зависимым (и, таким образом: почти избыточен) Фактическое сравнение двух полей ключа вместо ИМХО это не так уж проблематично с точки зрения производительности, а только вызовет уродливые запросы. Но я не знаю ваших данных ...

Подход хранилища данных к этой проблеме будет состоять в том, чтобы просто создать свой собственный суррогатный ключ (int или bigint) и использовать его вместо 128-битного монстра. Таблица поиска 1 <-> 1 сделает все остальное. Это также является решением проблемы изменения BigThing с течением времени, скажем, от char (64) с разрешенными только шестнадцатеричными символами к char (64) с полезной нагрузкой mmencoded.