Производительность по типу UUID PostgreSQL

Я не пытаюсь перезапустить дискуссию 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-дерева были другие преимущества по сравнению с хэш-индексом?

Ответы

Ответ 1

A UUID - значение 16 байтов. То же, что и text, составляет 32 байта. Размеры хранилища:

select
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::text) as text_size,
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::uuid) as uuid_size;
 text_size | uuid_size 
-----------+-----------
        36 |        16

Меньшие таблицы приводят к более быстрым операциям.

Ответ 2

У нас была таблица с 30-тысячными строками, в которых (по определенной несвязанной архитектурной причине) UUID хранились в текстовом поле и индексировались. Я заметил, что запрос выполнялся медленнее, чем я ожидал. Я создал новый столбец UUID, скопировал в текстовый первичный ключ uuid и сравнил ниже. 2,662 мс против 0,029 мс. Большая разница!

 -- With text index
    QUERY PLAN
    Index Scan using tmptable_pkey on tmptable (cost=0.41..1024.34 rows=1 width=1797) (actual time=0.183..2.632 rows=1 loops=1)
      Index Cond: (primarykey = '755ad490-9a34-4c9f-8027-45fa37632b04'::text)
    Planning time: 0.121 ms
    Execution time: 2.652 ms

    -- With a uuid index 
    QUERY PLAN
    Index Scan using idx_tmptable on tmptable (cost=0.29..2.51 rows=1 width=1797) (actual time=0.012..0.013 rows=1 loops=1)
      Index Cond: (uuidkey = '755ad490-9a34-4c9f-8027-45fa37632b04'::uuid)
    Planning time: 0.109 ms
    Execution time: 0.029 ms