Ответ
Хэш-индекс в PostgreSQL предназначен для очень быстрого поиска данных по точному совпадению (оператор =). Он работает, создавая хэш-таблицу, где ключом является хэш значения из индексируемого столбца.
Ключевые особенности
Преимущества:
- Высокая скорость: Поиск по точному совпадению в среднем выполняется за константное время O(1), что может быть быстрее, чем у B-Tree на больших таблицах.
- Компактность: Может занимать меньше места на диске по сравнению с B-Tree для некоторых типов данных.
Недостатки:
- Ограниченность запросов: Не поддерживает операции сравнения диапазонов (
<,>,BETWEEN), сортировку (ORDER BY) или поиск по префиксу (LIKE 'prefix%'). Работает только для оператора равенства. - Проблемы с репликацией (в старых версиях): До PostgreSQL 10 хэш-индексы не логировались в WAL (Write-Ahead Log), что делало их небезопасными для репликации. Эта проблема решена начиная с PG 10.
Пример создания:
-- Создание хэш-индекса для колонки email в таблице users
CREATE INDEX idx_users_email_hash ON users USING HASH (email);Итог
Используйте хэш-индекс, когда вам нужны только запросы на точное равенство для колонки с высокой кардинальностью (много уникальных значений), и вы не планируете использовать эту колонку для сортировки или диапазонных запросов. В большинстве других случаев B-Tree является более универсальным и предпочтительным выбором.
Ответ 18+ 🔞
А, слушай-ка, про хэш-индексы в постгресе! Ну это ж, блядь, как молоток, который забивает только один гвоздь, но зато ебёт как бог.
Представь себе, есть у тебя столбец, ну там email какой-нибудь. И тебе надо найти запись ТОЧНО по нему, чтобы ни хуя больше. Не «начинается с», не «больше-меньше», а вот это вот пиздецкое, конкретное равенство. Вот для этого эта штука и создана.
Что он умеет, этот хитрожопый?
- Скорость, блядь, конская: В идеале находит за O(1), то есть почти мгновенно. На больших объёмах данных может B-Tree обставить, как лохушку.
- Места жрёт поменьше: Иногда компактнее своего универсального собрата-дерева.
А где он, сука, лажает?
- Узкий специалист, пидарас: Никаких «больше-меньше», никакого
LIKE 'vasya%', никакой сортировки по нему. Только=и всё, пиздец. Хочешь что-то ещё — иди нахуй, в B-Tree. - Раньше был совсем конченый: До десятой версии его в WAL не писали, так что после сбоя он мог просто исчезнуть, как твоя зарплата в пятницу вечером. Но щас, с десятой версии, эту хуйню починили, можно спать спокойно.
Как его, этого урода, вызвать к жизни?
-- Вешаем хэш-индекс на почту юзеров, чтобы искать их на раз-два
CREATE INDEX idx_users_email_hash ON users USING HASH (email);Короче, вывод, ёпта:
Если у тебя колонка с кучей уникальных значений и ты с неё будешь делать ТОЛЬКО точный поиск (WHERE email = 'vasya@ebanya.ru'), то хэш — твой выбор, овердохуища быстрый.
Но если хоть краем ебала думаешь про диапазоны или сортировку — даже не мучайся, бери B-Tree, он хоть и не такой шустрый в одной узкой дисциплине, зато мультитул, блядь, на все случаи жизни.