Разница в производительности между UUID, CHAR и VARCHAR в таблице PostgreSql?
Я храню значения UUID v4 в PostgreSQL v9.4 таблица в колонке "id".
когда я создаю таблицу, есть ли разница в следующем выполнении записи или чтения, определяю ли я столбец "id" как ВАРЧАР (36), ЧАР(36) или UUID тип данных?
спасибо!
3 ответов
использовать uuid
. PostgreSQL имеет собственный тип по какой-то причине.
он хранит uuid внутри как 128-битное двоичное поле. Ваши другие предлагаемые варианты хранят его как шестнадцатеричный, что очень неэффективно по сравнению.
не только это, но и:
uuid
делает простую bytewise сортировку для заказа.text
,char
иvarchar
рассмотрим параметры сортировки и локали, что бессмысленно для идентификатор UUID.есть только один канонический respresentation о
uuid
. То же самое не верно для текста и т. д.; Вы должны учитывать верхний и нижний регистр, наличие или отсутствие{...-...}
s etc.
нет никаких сомнений. Использовать uuid
.
единственный другой тип, который имеет смысл, это bytea
, который по крайней мере можно использовать для хранения 16 байтов uuid напрямую. Это то, что я бы сделал, если бы использовал системы, которые не могут справляйтесь с типами данных вне базового набора, например, с действительно тупым ORM.
UUID будет самым быстрым, потому что его 128 бит -> 16 байт и сравнения выполняются численно.
Char (36) и varchar(36) кажутся одинаковыми и медленными: http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/.
сервер должен проверить EOF, чтобы определить задание чтения значения завершено или нет для каждого символа.
также сравнение текста медленнее, чем числовое сравнение. И потому, что UUID состоит из 16 байтов сравнение UUID намного быстрее, чем сравнение двух текстов из 36 символов.
используйте собственный UUID для производительности.
размер индекса, возможно, самая заметная разница: почти на 86% больше для VARCHAR.
с точки зрения производительности я не заметил существенных различий в PostgreSQL 9.5.