Как Postgres выполняет запрос

Пять стадий

Твоя SQL-строка не выполняется напрямую. Backend Postgres, владеющий твоим соединением, проталкивает её через конвейер:

1. Parse — сырой текст проверяется на синтаксис и превращается в parse tree (дерево разбора — внутреннее представление запроса в виде узлов). Пропущенная запятая или SELCT умирают здесь. Таблицы ещё не трогаются; парсер даже не знает, существует ли orders.
2. Analyze (семантика) — имена разрешаются по каталогу. Существует ли orders? Есть ли колонка id? Какие типы участвуют? Ошибка «column does not exist» рождается здесь, а не в парсере.
3. Rewrite — применяются rule-based преобразования. Главное: запрос к представлению (view) переписывается в запрос к нижележащим таблицам; сюда же внедряются политики row-level security и правила.
4. Plan / optimize — планировщик берёт проанализированное дерево запроса и строит физический план: какой скан (sequential? index?), какой алгоритм join (nested loop? hash? merge?), в каком порядке. Он использует статистику таблиц, чтобы оценить число строк, и выбирает самый дешёвый план по внутренней стоимостной модели.
5. Execute — исполнитель обходит выбранное дерево плана, протягивая строки сквозь него узел за узлом, и стримит результат тебе.

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

Почему стадии важны для отладки

Когда запрос ведёт себя неправильно, большинство инженеров сразу переписывают SQL — и тратят час, меняя текст, который никогда не был проблемой. Конвейер даёт более быстрый путь: сопоставь симптом со стадией, исправь именно там.

Конвейер — это диагностическая карта. Сопоставь симптом со стадией:

• Синтаксическая ошибка → стадия parse. Чисто текстовая проблема; схема не важна.
• «relation/column does not exist» → стадия analyze. Текст — валидный SQL, но не совпадает с каталогом.
• Запрос внезапно медленный после загрузки данных → стадия plan. Оценки строк у планировщика устарели, и он выбрал плохой план. Фикс обычно — ANALYZE, чтобы обновить статистику, а не переписывание запроса.
• Запрос всегда медленный, план выглядит верно → стадия execute. План в порядке, но он реально читает слишком много страниц; фикс — индекс или меньше данных, что меняет, какие планы вообще доступны.

Поэтому сеньорский рефлекс — EXPLAIN. EXPLAIN <query> показывает план, выбранный планировщиком, не выполняя запрос; EXPLAIN ANALYZE <query> выполняет его и показывает оценочные против фактических строк в каждом узле. Зазор между оценкой и фактом — самое полезное число в работе над производительностью Postgres: он говорит, обманули ли планировщик устаревшей статистикой.

-- Только план (быстро, без выполнения):
EXPLAIN SELECT * FROM orders WHERE id = 42;

-- Выполнить и сравнить оценку с реальностью:
EXPLAIN ANALYZE SELECT * FROM orders WHERE id = 42;

Ты пока не прочитаешь план целиком — это отдельный раздел дальше (08-internals-and-tuning), а трек databases глубоко разбирает планировщик и внутренности планов выполнения. Сейчас усвой только форму: текст внутрь, пять стадий, строки наружу, а EXPLAIN — твоё окно в четвёртую стадию.