Я не пытаюсь перезапустить дискуссию UUID и серийный ключ. Я знаю, что с обеих сторон есть действительные баллы. Я использую UUID в качестве основного ключа в нескольких моих таблицах.
- Тип столбца:
"uuidKey" text NOT NULL
- Индекс:
CREATE UNIQUE INDEX grand_pkey ON grand USING btree ("uuidKey")
- Ограничение первичного ключа:
ADD CONSTRAINT grand_pkey PRIMARY KEY ("uuidKey");
Вот мой первый вопрос; с PostgreSQL 9.4 есть ли какое-либо преимущество в производительности для установки типа столбца в UUID?
Документация http://www.postgresql.org/docs/9.4/static/datatype-uuid.html описывает UUID, но есть ли какие-либо преимущества помимо безопасности типа для использования этого типа вместо типа text
? В документации типов символов это означает, что char(n)
не будет иметь преимуществ перед text
в PostgreSQL.
Совет. Между этими тремя типами нет разницы в производительности. из увеличенного пространства для хранения при использовании пустого запаса и несколько дополнительных циклов процессора для проверки длины при хранении в столбец с ограничениями длины. Хотя характер (n) имеет производительность преимущества в некоторых других системах баз данных, нет такого преимущества в PostgreSQL; на самом деле характер (n) обычно является самым медленным из три из-за его дополнительных затрат на хранение. В большинстве ситуаций текст или вместо символа.
Меня не беспокоит дисковое пространство, мне просто интересно, стоит ли мне сравнивать тесты UUID и текстовых столбцов?
Второй вопрос, хеш против индексов b-дерева. Нет смысла сортировать ключи UUID, чтобы у b-дерева были другие преимущества по сравнению с хэш-индексом?