Статистика и промах в оценке

Что планировщик знает о твоих данных

Прежде чем чинить плохую оценку, нужно знать, что именно планировщик читает. Каждая оценка планировщика (урок 02) идёт из одного места: каталога pg_statistic, читаемого через вью pg_stats. ANALYZE (вручную или автоматически через autovacuum — урок 04) семплирует каждую таблицу и хранит три вещи на колонку. Глава статистики трека databases разбирает внутренности семплирования; здесь читаем это как рычаги, которые дёргает SQL-автор:

• n_distinct — сколько различных значений в колонке. Ведёт оценку «сколько строк совпадёт с одним значением?» → примерно row_count / n_distinct.
• Most Common Values (most_common_vals + most_common_freqs) — топ-значения и их точные частоты. Для status = 'placed' планировщик не гадает; он читает сохранённую частоту. Поэтому перекошенные колонки хорошо оцениваются для частых значений.
• Гистограмма (histogram_bounds) — корзины равного числа строк для всего, что не в списке MCV, для диапазонных предикатов вроде total > 100.

-- Осмотри, во что планировщик верит про колонку:
SELECT attname, n_distinct, most_common_vals, most_common_freqs
FROM pg_stats
WHERE tablename = 'orders' AND attname = 'status';

default_statistics_target (по умолчанию 100) управляет, сколько записей MCV и корзин гистограммы хранится. Подними его на колонке со множеством различных значений или сильным перекосом (ALTER TABLE orders ALTER COLUMN status SET STATISTICS 1000;), меняя более медленный ANALYZE на более резкие оценки.

Ловушка коррелированных колонок

Вот математика, которая ломается. По умолчанию планировщик оценивает многоколоночный фильтр, считая колонки независимыми: он перемножает их индивидуальные селективности. Для WHERE city = 'Paris' AND country = 'France':

оценка = P(city='Paris') × P(country='France') × row_count

Если 1% строк — Paris, а 2% — France, планировщик предскажет 0.01 × 0.02 = 0.0002 → 0.02% строк. Но city и country функционально зависимы — каждая строка Paris и есть строка France. Реальная селективность — просто 1%, в пятьдесят раз выше. Планировщик недооценивает в ~50×, ждёт горстку строк, выбирает nested loop и детонирует, когда реальность выдаёт 480 000.

Это самый частый сеньорский промах оценки на проде, и он невидим, пока поверх него не построят join. Допущение независимости нормально для действительно несвязанных колонок; оно катастрофично для коррелированных (city/country, brand/model, zip/state, status/shipped_at).

Фикс — extended statistics — ты говоришь Postgres, что эти колонки ходят вместе:

CREATE STATISTICS orders_city_country (dependencies, ndistinct, mcv)
  ON city, country FROM orders;
ANALYZE orders;   -- extended stats заполняются только на следующем ANALYZE

Три вида, каждый чинит свой промах:

• dependencies — захватывает функциональную зависимость (Paris ⇒ France), чиня недооценку перемноженной селективности выше.
• ndistinct — захватывает комбинированное число различных значений группы колонок, чиня оценки GROUP BY a, b (независимость пересчитывает группы).
• mcv — многоколоночный список most-common-values для перекошенных комбинаций.

Все три атакуют один корень: планировщик рассуждал о колонках по отдельности. Без dependencies получаешь взрывной nested loop; без ndistinct GROUP BY завышает число групп и тратит лишнюю память на хэш-таблицу; без mcv запросы по редким комбинациям получают усреднённую оценку, промахивающуюся в любую сторону.

После CREATE STATISTICS + ANALYZE тот же запрос перепланируется: оценка 480 000, факт 480 000, планировщик берёт hash join, 22 с → 60 мс. Без переписывания запроса, без индекса, без хинта — ты поправил оценку.