lesson ── postgres-labs ── ~20 мин ── 4 шагов
Один и тот же запрос пройдём по стадиям: посмотрим, как ошибка имени
ловится на анализе, а не на разборе, и как представление растворяется
при переписывании. Запусти psql во вкладке client.
интерактивный sandbox
Поднимется контейнер postgreslab/postgres-base с PostgreSQL 17 и psql. В браузере откроется терминал, база lab уже настроена. Каждый шаг проверяется автоматически. Сеть air-gapped, наружу контейнер не ходит.
stack ── PostgreSQL 17 · psql · 1 GB RAM · air-gapped · самоуничтожается через 45 мин простоя
Разбор проверяет только грамматику; имена связываются на анализе. Запусти заведомо синтаксически верный, но семантически неверный запрос:
SELECT nope FROM flights;
Ошибка column "nope" does not exist приходит на стадии анализа -
грамматика-то корректна. Это первая стадия, где сервер заглянул в
каталог. Теперь проверим, что таблица flights существует и
доступна.
Синтаксис верный, поэтому разбор проходит; падает связывание имени с каталогом.
✓ flights на месте; ошибка имени рождается на анализе, не разборе.
View - это сохранённый запрос, не данные:
CREATE VIEW svo AS SELECT * FROM flights WHERE departure = 'SVO';
CREATE VIEW не копирует строки - хранит только определение запроса.
✓ Представление создано.
Сравни план запроса через view и прямого запроса:
EXPLAIN SELECT flight_no FROM svo WHERE arrival = 'LED';
EXPLAIN SELECT flight_no FROM flights WHERE departure = 'SVO' AND arrival = 'LED';
Оба условия (departure и arrival) применены к одному скану flights - подзапрос view сплющен. Планы совпадают.
Переписывание подставило определение view, планировщик сплющил подзапрос.
✓ View растворился в скан flights - сам по себе он не замедляет.
EXPLAIN SELECT t.passenger
FROM tickets t JOIN flights f ON f.flight_id = t.flight_id
WHERE f.departure = 'SVO';
Читай снизу вверх: листья - сканы таблиц, наверху - узел соединения, отдающий результат. cost/rows/width - оценки планировщика.
Дерево плана читается снизу вверх и изнутри наружу.
✓ Видно дерево плана с узлом соединения наверху.
Запрос проходит пять стадий: разбор (грамматика), анализ (имена и типы), переписывание (раскрытие view и RLS), планирование (выбор плана), выполнение. Стадии 1-3 про «что», стадия 4 про «как». View - сохранённый запрос; он сплющивается при планировании и не замедляет.
команды
EXPLAIN SELECT ...;показать дерево плана без выполненияCREATE VIEW v AS SELECT ...;сохранить запрос как представлениеконцепции