PostgreSQL HASH-индекс

Question

Кто-нибудь знает ситуацию, когда вместо B-TREE следует использовать HASH PostgreSQL, поскольку мне кажется, что эти вещи - ловушка. Они занимают намного больше времени на СОЗДАНИЕ или обслуживание, чем B-TREE (как минимум, в 10 раз больше), они также занимают больше места (для одного из моих таблиц table.columns B-TREE занимает 240 МБ, тогда как HASH возьмите 4 ГБ), и я, похоже, понял из своего поиска в Google, что они НЕ ВЫБИРАЮТСЯ быстрее, чем B-TREE; все же HASH, возможно, был недавно оптимизирован или Google был не прав.

В любом случае, я хотел узнать мнение и опыт вашего парня. Если эти ХАШы злые, люди должны знать.

Спасибо
Кроме того: как насчет хешей MySQL?

Answer 1

Хеши быстрее, чем B-деревья, в случаях, когда у вас есть известное значение ключа, особенно известное уникальное значение.

Хэши следует использовать, если рассматриваемый столбец никогда , предназначенный для сравнительного сканирования с помощью команд < или >.

Хэши O(1) сложности, B-деревья O(log n) сложности (iirc), следовательно, для больших таблиц с уникальными записями, извлекающими ITEM="foo", они будут наиболее эффективным способом поиска.

Это особенно практично, когда эти уникальные поля используются при условии соединения.

Answer 2

Лучше использовать индекс Hash для текстовых столбцов, поиск которых осуществляется только с помощью оператора =. Например, столбец URL, который необходимо проиндексировать для поиска.

Индекс хэша составляет примерно 30% размера индекса B-Tree для чего-то вроде URL.

Уменьшенный размер позволяет PostgreSQL более эффективно использовать свою кеш-память (Aka, shared_buffers).

Answer 3

Как http://www.postgresql.org/docs/9.2/static/sql-createindex.html точка Хэш-индекс все еще не безопасен для WAL; Это означает, что они не являются на 100% надежными для сбоев (индекс должен быть восстановлен, и при репликации может возникнуть неправильный ответ). Проверьте также http://www.postgresql.org/docs/9.1/static/wal-intro.html

Answer 4

Я не пробовал этого, но рассматриваю этот подход, чтобы использовать хеш-индексы для временных журнальных таблиц.

Насколько я понимаю, они строятся быстрее, занимают меньше места и выполняют запросы немного быстрее, чем b-tree.

Согласно этому бенчмарку хеш-индексы немного быстрее и несколько меньше, чем индексы BTree. Однако с ними нельзя создать уникальный хэш-индекс - кроме того, они не зарегистрированы в WAL.