Жизнь запроса: от текста до результата

Запрос внутри сервера проходит строго по порядку:

1. Разбор (parse). Текст SQL превращается в дерево разбора по грамматике. Здесь ловятся синтаксические ошибки. Сервер ещё не знает, существует ли таблица flights - он только убедился, что это синтаксически корректный SELECT.
2. Семантический анализ (analyze). Имена связываются с объектами: flights ищется в каталоге, проверяются типы, раскрываются *. Получается дерево запроса (query tree) - уже осмысленное.
3. Переписывание (rewrite). Система правил подставляет определения представлений, применяет RLS-политики, разворачивает некоторые конструкции. На входе и выходе - дерево запроса.
4. Планирование (plan). Планировщик перебирает способы выполнить запрос и выбирает самый дешёвый. Результат - дерево плана: какие сканы, в каком порядке, какими соединениями.
5. Выполнение (execute). Исполнитель идёт по дереву плана и выдаёт строки.

Ключ к пониманию: стадии 1-3 про что нужно получить, стадия 4 про как. Один и тот же запрос всегда даёт одно дерево запроса, но разные планы - в зависимости от данных, статистики и настроек.

Разбор работает только с грамматикой. SELECT * FROM flights WHERE x = 1 разберётся, даже если колонки x нет - синтаксис-то верный. Ошибка «column x does not exist» прилетает на следующей стадии, когда имена связываются с каталогом.

Семантический анализ делает несколько вещей за раз: находит таблицы и колонки по именам (с учётом search_path), проставляет типы выражений и при необходимости вставляет приведения, раскрывает * в список колонок, проверяет права. Если приведение типа неявное и неудачное, именно здесь рождаются неожиданности - о них подробно в главе про чтение планов.

Результат - дерево запроса: структура «что выбрать, откуда, по какому условию, как сгруппировать и отсортировать», без единого слова о том, как это исполнять физически.

Третья стадия - система правил. Главная её работа на практике - раскрытие представлений. Представление в PostgreSQL не хранит данные; это сохранённый запрос. Когда ты обращаешься к view, его определение подставляется в твой запрос как подзапрос.

CREATE VIEW svo_flights AS

  SELECT * FROM flights WHERE departure = 'SVO';

-- Этот запрос:

SELECT flight_no FROM svo_flights WHERE arrival = 'LED';

-- после переписывания превращается примерно в:

SELECT flight_no FROM (SELECT * FROM flights WHERE departure = 'SVO') v

WHERE v.arrival = 'LED';

Дальше планировщик чаще всего «сплющит» подзапрос обратно в один уровень и применит оба условия к одному скану flights. Поэтому view сам по себе не делает запрос медленнее - он растворяется ещё до планирования. На этой же стадии применяются политики row-level security: к запросу автоматически добавляются условия, ограничивающие видимые строки. Подробнее - в query-rewrite.

Четвёртая стадия - сердце части VI. Дерево запроса говорит «нужны рейсы из SVO в LED». Способов получить их физически - много: прочитать всю таблицу и отфильтровать, пройти по индексу на departure, по индексу на arrival, пересечь два индекса. Если в запросе соединение, добавляется выбор алгоритма (nested loop, hash, merge) и порядка соединения.

Планировщик оценивает стоимость каждого варианта в условных единицах и выбирает самый дешёвый. Это не поиск «правильного» плана, а ставка на основе статистики о данных. Если статистика врёт, ставка проигрывает - и запрос тормозит, хотя формально всё «оптимально». Как считается стоимость - в cost-model, откуда берутся числа о данных - в planner-statistics.

Результат планирования - дерево узлов, и EXPLAIN показывает его как есть, без выполнения:

EXPLAIN SELECT t.passenger

FROM tickets t JOIN flights f ON f.flight_id = t.flight_id

WHERE f.departure = 'SVO';

Hash Join  (cost=2.12..18.40 rows=120 width=12)

  Hash Cond: (t.flight_id = f.flight_id)

  ->  Seq Scan on tickets t  (cost=0.00..14.00 rows=500 width=8)

  ->  Hash  (cost=1.62..1.62 rows=40 width=4)

        ->  Seq Scan on flights f  (cost=0.00..1.62 rows=40 width=4)

              Filter: (departure = 'SVO')

Дерево читается снизу вверх и изнутри наружу: листья - сканы таблиц, они отдают строки родителям, наверху - финальный узел, отдающий результат клиенту. Каждый узел показывает оценку стоимости (cost), числа строк (rows) и ширину (width). Это план, а не факт: чтобы увидеть реальные числа, нужен EXPLAIN ANALYZE, которому посвящена глава 30.

Есть два способа отправить запрос на сервер. Простой протокол - одна команда «вот текст, выполни» - проходит все пять стадий за раз. Так работает psql, когда ты вводишь запрос целиком.

Расширенный протокол разбивает это на шаги: Parse (разобрать и запомнить под именем), Bind (подставить параметры $1, $2), Execute (выполнить). Так работают подготовленные выражения и драйверы приложений. Выигрыш в том, что стадии разбора и анализа можно сделать один раз, а выполнять много - с разными параметрами.

Это открывает дверь к кешу планов: подготовленное выражение может запомнить не только разобранный запрос, но и план. Когда это выгодно, а когда нет (generic против custom plan) - тема главы 29.

Разделение «что» и «как» - это и есть причина, по которой PostgreSQL вообще можно оптимизировать. Ты пишешь декларативный SQL (что хочешь), а планировщик каждый раз решает, как это сделать, исходя из текущих данных. Поменялся объём таблицы или статистика - план для того же текста сменится сам.

Практический вывод: когда запрос «вдруг стал медленным», текст SQL обычно ни при чём - сменился план. Поэтому диагностика начинается не с переписывания запроса, а с EXPLAIN: посмотреть, какой план выбран сейчас, и сравнить с тем, что планировщик считал, когда было быстро. Этим и займёмся в оставшихся главах части.