Индекс HASH PostgreSQL

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

Во всяком случае, я хотел, чтобы вы были мнением и опытом. Люди должны знать это.

Спасибо
Также: как насчет MySQL HASH?

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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