Индексы — важнейший инструмент оптимизации запросов в базах данных. В PostgreSQL одним из вариантов является хеш-индекс. В отличие от B-tree, он работает исключительно с операциями равенства (=) и использует бакеты для хранения ссылок на строки таблицы. Давайте разберёмся, как PostgreSQL управляет этими бакетами, какие особенности у хеш-индекса и в каких случаях его применение оправдано.

Что такое бакеты в хеш-индексе PostgreSQL?

При создании хеш-индекса PostgreSQL применяет хеш-функцию к каждому значению индексируемого столбца. Результат хеширования определяет, в какой бакет (bucket) попадёт запись.

? Формула назначения бакета: bucket_number = hash_value mod num_buckets

Это означает, что PostgreSQL делит хеш-значение на количество бакетов и использует остаток от деления для распределения данных.

Сравнение хеш-индекса и B-tree в цифрах

Рассмотрим производительность индексов на таблицах разного размера:

? Вывод: B-tree выигрывает при поиске по диапазону (<, >, BETWEEN). Однако, если запросы используют только =, хеш-индекс оказывается быстрее, особенно на больших объёмах данных.

Как бакеты хранят данные?

Каждый бакет содержит страницы размером 8 Кб. В одной странице хранятся:

• Заголовок (≈ 24 байта)

• Хеш-значения ключей (по 4 байта)

• Указатели на строки таблицы (tuple ID, TID) (по 6 байт)

⚠️ Важно: хеш-индекс хранит не ключ, а только его хеш-значение (в отличие от B-Tree).
Тогда на одной странице можно разместить (8Кб - 24б) / (4б + 6б) ≈ 800 записей.

Что происходит, если бакет переполняется?

Если количество записей в бакете превышает размер одной страницы, PostgreSQL создаёт страницы переполнения (overflow pages). Это замедляет работу индекса, так как поиск требует сканирования нескольких страниц.

? Оптимальный сценарий:
✔️ Значения равномерно распределены по бакетам.
✔️ Коллизии хеш-функции минимальны.
✔️ Доступ выполняется в O(1) (константное время).

? Проблемный сценарий:
❌ Записи с одинаковыми значениями хешируются в один бакет.
❌ Создаются страницы переполнения → поиск замедляется.
❌ PostgreSQL вынужден сканировать длинные цепочки записей.

Как проверить состояние хеш-индекса?

PostgreSQL не предоставляет встроенных средств просмотра количества бакетов, но можно воспользоваться расширением pageinspect:

CREATE EXTENSION IF NOT EXISTS pageinspect;
SELECT * FROM hash_page_stats('my_hash_index', 0);

Также можно проверить статистику использования индекса:

SELECT indexrelid::regclass, idx_scan, idx_tup_read, idx_tup_fetch 
FROM pg_stat_user_indexes 
WHERE indexrelid = 'my_hash_index'::regclass;

Если idx_scan (количество использований) низкое, а idx_tup_read (количество прочитанных строк) высокое, это может указывать на переполнение бакетов.

Когда стоит (и не стоит) использовать хеш-индекс?

✔️ Подходит, если:

• Данные размером от 100 тыс. до 50 млн. строк.

• Только операции =, без диапазонных запросов.

• Равномерное распределение значений (минимальные коллизии).

• Запросы выполняются очень часто (например, кэш-таблица).

❌ Не подходит, если:

• Менее 100 тыс. записей → PostgreSQL и так быстро сканирует таблицу.

• Более 50 млн. записей → бакеты переполняются, индексация замедляется.

• Запросы с диапазонами (<, >, BETWEEN) → хеш-индекс не поддерживает.

• Много дубликатов → это приводит к переполнению страниц и снижению производительности.

Оптимизация хеш-индекса

Если индекс замедляется из-за переполнения бакетов, попробуйте:

✔️ Перестроить индекс заново, освобождая неиспользуемое пространство и улучшая производительность запросов REINDEX INDEX my_index;

✔️ Использовать B-tree, если есть диапазонные запросы.

✔️ Разделить таблицу на партиции, если данные стремительно растут.

Выводы

? Хеш-индексы ускоряют поиск при = и равномерных данных.

? Переполнение бакетов снижает производительность.

? B-tree лучше при диапазонных запросах.

Если данные динамически изменяются и содержат много дубликатов, B-tree может оказаться более эффективным. Однако, при правильных условиях хеш-индекс даёт отличную скорость поиска, особенно на больших объёмах данных с точными соответствиями. ?