Когда запрос в PostgreSQL тормозит, хочется добавить индекс. Но иногда это не лечит причину: индекс хранит лишнее, занимает место, замедляет запись или вообще не нужен, потому что схема уже знает, что подходящих строк нет.

Разберем три такие ситуации.

1️⃣ Результат заранее пустой

Если в таблице есть check-ограничение с тарифами free и pro, строк со значением Pro там быть не может. При constraint_exclusion = on PostgreSQL использует это знание и не сканирует таблицу зря.

2️⃣ Запросу не нужна вся точность колонки

Если отчет строится по дням, индекс по timestamp хранит лишние часы, минуты и секунды. Индекс по выражению с датой занимает меньше места и дает запросу нужную точность.

3️⃣ Уникальность нужна, большой B-Tree — нет

Для длинных URL уникальный B-Tree может разрастись почти до размера таблицы. Если на URL не ссылаются внешние ключи и не нужен ON CONFLICT DO UPDATE, уникальность можно проверять через exclusion constraint и hash-индекс. Так индекс получается намного меньше.

У каждого приема есть цена: constraint_exclusion тратит больше времени на планирование, индекс по выражению ломается от другого синтаксиса, а hash-индекс через exclusion constraint подходит не всем сценариям уникальности.

Но в этом и смысл. Оптимизация начинается с вопроса: что именно мешает запросу работать быстрее? Лишнее сканирование, лишняя точность, слишком большой индекс или неявное знание, которое схема уже хранит, но планировщик не использует.

Когда ответ понятен, решение оказывается проще и дешевле, чем добавление еще одного индекса.

📜 Подробности читайте на Хабре.

📢 Читайте нас в MAX