Стоимостный планировщик

Как он выбирает: по стоимости, не по правилам

Когда на проде кусает «неверный план», ответ почти никогда не в новом синтаксисе SQL — а в понимании, какое число планировщик взял неверно. Планировщик берёт проанализированный запрос и перечисляет кандидатные физические планы — разные методы скана, разные алгоритмы join, разные порядки join’ов — затем присваивает каждому числовую стоимость и берёт минимальную. Глава об execution-plans трека databases глубоко выводит стоимостную модель и таксономию сканов/join’ов; здесь суть — цикл решения, который SQL-автор видит снаружи.

Стоимость складывается из оценочного числа строк (из статистики, урок 03), умноженного на константы операций. Самые важные дефолты: seq_page_cost = 1.0 (читать страницу последовательно), random_page_cost = 4.0 (читать страницу случайно), cpu_tuple_cost = 0.01 (обработать строку). Index scan делает случайные чтения страниц; sequential scan — дешёвые последовательные. Поэтому вердикт планировщика «index или seq scan?» это на самом деле арифметика: сколько строк совпадает × случайная цена против вся таблица × последовательная цена.

Выбор скана для WHERE status = 'shipped':

• Мало совпадающих строк → Index Scan (дёшево прыгнуть прямо к ним).
• Много совпадающих строк → Seq Scan (случайный I/O на строку стоил бы больше, чем прочитать всю таблицу по порядку). Это правильно, а не баг — Seq Scan по неселективному фильтру обгоняет индекс.
• Средняя доля → Bitmap Index Scan (собрать указатели на совпадающие страницы, отсортировать их, прочитать страницы в физическом порядке — точность индекса без случайной молотьбы).

Выбор join для orders ⋈ line_items:

• Крошечная внешняя сторона → Nested Loop (для каждой внешней строки зондировать индекс на внутренней — отлично, когда «мало × индексный поиск»).
• Две большие несортированные стороны → Hash Join (построить hash-таблицу на меньшей, прогнать большую мимо неё).
• Два уже отсортированных входа → Merge Join (идти по обоим в ногу).

-- Смотри, как скан переключается при смене селективности:
EXPLAIN SELECT * FROM orders WHERE status = 'cancelled';  -- редко → Index Scan
EXPLAIN SELECT * FROM orders WHERE status = 'placed';     -- часто → Seq Scan

Почему в Postgres нет хинтов

Oracle и SQL Server дают прибить план хинтом. Postgres отказывает, и логика устойчива: хинт — это замороженное решение против движущегося набора данных. Запрос, который ты сегодня хинтишь «используй индекс», — это запрос, который через год делает 50M случайных чтений, когда таблица выросла и индекс перестал быть селективным. Планировщик, накормленный свежей статистикой, сам бы переключился на Seq Scan. Хинт запрещает эту адаптацию.

Поэтому сеньорский воркфлоу — починить входы, чтобы планировщик сам пришёл к верному плану:

1. Статистика — запусти ANALYZE или подними default_statistics_target / добавь extended statistics (урок 03). Большинство «плохих планов» — это плохие оценки.
2. Индексы — добавь или удали индекс, чтобы сменить множество кандидатов. Планировщик берёт только из доступного.
3. Конфиг — на SSD/NVMe random_page_cost = 4.0 это дефолт для вращающихся дисков, дико перенаказывающий index scan; снижение до 1.1 — самая частая прод-правка. effective_cache_size говорит планировщику, на сколько OS-кеша он может рассчитывать.
4. Переписать запрос — иногда LATERAL, EXISTS вместо IN или разбиение запроса меняют пространство кандидатов к лучшему.
5. join_collapse_limit — после ~8 соединяемых таблиц планировщик перестаёт исчерпывающе переставлять join’ы (пространство поиска факториально) и доверяет твоему порядку. Повышение даёт оптимизировать большие join’ы ценой времени планирования.

Вместе эти входы — статистика, индексы, константы стоимости и форма запроса — это всё, с чем работает планировщик. Почини любой из них правильно, и планировщик сам выведет хороший план; перескочи к управлению выходом — и получишь хрупкий замороженный план, который больно ударит при росте данных.