Запросы к графам в Postgres 19 — это начало пути, а не конечная точка.

Postgres использует прагматичный, поэтапный подход к добавлению функциональности. Например, ещё в 2012 году Postgres добавил первую поддержку JSON.

Craig Kerstiens заявил: «мы жульничали», потому что это было просто текстовое поле с наложенной валидацией JSON. Два года спустя был выпущен JSONB. В новых релизах продолжают добавляться дополнительные возможности индексации и операторы. Сейчас и JSON, и JSONB имеют своё место.

Мы ожидаем, что реализация SQL/PGQ в Postgres 19 будет аналогичной. Первоначальный релиз, скорее всего, не заменит существующие рабочие процессы. Он ограничен запросами фиксированной глубины, что уже достаточно просто реализуется с текущим SQL.

Но с чего-то же нужно начинать!

Что реализовано?

DDL-определение: граф объявляется и получает имя.
CREATE PROPERTY GRAPH org_graph указывает, какие таблицы являются вершинами и рёбрами, один раз. Запросы могут ссылаться на граф по имени. Изменения схемы распространяются автоматически, выдаются понятные ошибки, если запрос ссылается на вершину/ребро, которого больше нет, и нельзя удалять таблицы с связанными графами.

Когда-нибудь писали большой CTE-запрос, который сломался из-за изменения схемы? Да, я тоже.

Синтаксис запросов: синтаксис соответствует стандарту SQL:2023. Например, (a)<-[IS reports_to]-(b) означает, что b подчиняется a.

Вы получаете стандартную компонуемость SQL, потому что GRAPH_TABLE ведёт себя как таблица. Его можно джойнить, фильтровать, агрегировать, помещать в CTE и использовать как новый источник в FROM.
Реализованный подход отвечает на вопрос: «Что можно построить минимально, чтобы уже начать работать?» Ответ, судя по всему, — поддержка DDL и поддерживаемый синтаксис запросов.

Что SQL/PGQ пока не умеет, а рекурсивные CTE делают лучше:

Переменная глубина: если нужны все потомки на любой глубине, SQL/PGQ в Postgres 19 поддерживает только фиксированную глубину. Каждое “прыжковое” соединение нужно явно прописывать, что требует знать максимальную глубину на этапе написания запроса и делает запрос длинным.

Агрегация вдоль пути: CTE умеют накапливать массивы, конкатенировать пути, вычислять промежуточные суммы во время рекурсии.

Как и с поддержкой JSON, просто подождите: через несколько релизов вы оглянетесь и скажете: «О, теперь это тоже можно делать».

👉 @SQLPortal

Подготовленные выражения и подготовленные транзакции — это полностью разные возможности Postgres, которые совпадают только по слову в названии. Одна используется широко и безопасна. Вторая применяется редко и при неправильном управлении может приводить к простоям.

Начнём с безопасной:
Подготовленные выражения (PREPARE / EXECUTE)

Часто используемая функция оптимизации запросов. SQL-выражение парсится один раз, затем выполняется много раз с разными параметрами. Снижает накладные расходы на парсинг и иногда на построение плана выполнения:

PREPARE find_user (text) AS 
SELECT * FROM users WHERE email = $1;

EXECUTE find_user('alice@example.com');
EXECUTE find_user('bob@example.com');

DEALLOCATE find_user;

• Живёт в пределах одной сессии
• Хранится в памяти, без долговременного хранения
• Безопасно при «забывании»
• Видно через SELECT * FROM pg_prepared_statements
• Используется большинством фреймворков, ORM и библиотек для оптимизации
Подготовленные транзакции (PREPARE TRANSACTION / COMMIT PREPARED)
Большинству приложений эта функциональность не нужна.
Это реализация Postgres двухфазного коммита (2PC / XA транзакции). Транзакция переводится в состояние «готова к фиксации», фиксируется на диске, а завершение выполняется позже из другой сессии:

BEGIN;
INSERT INTO orders VALUES (1, 'widget', 99);
PREPARE TRANSACTION 'order_txn_abc123';

-- позже
COMMIT PREPARED 'order_txn_abc123';
-- или: ROLLBACK PREPARED 'order_txn_abc123';

• Переживает падения и перезапуски (запись в pg_twophase/ внутри каталога)
• Держит блокировки до завершения
• Удерживает идентификатор транзакции (XID) и блокирует автоочистку (vacuum)
• Блокирует DDL-операции над затронутыми таблицами
• Требует max_prepared_transactions > 0 (по умолчанию 0 — одно из удачных значений по умолчанию)

👉 @SQLPortal

Ожидается, что в Postgres 19 появится новое contrib-расширение pg_plan_advice, которое добавит пользовательские хинты. Но как Postgres столько лет обходился без хинтов, пока другие СУБД на них опирались? Статистика.

Начиная с 1998 года, Postgres использует статистику на уровне колонок для генерации планов запросов. Алгоритм много раз улучшался и давно считается хорошо проверенной системой выбора плана выполнения на основе статистики. Статистика, которую генерирует ANALYZE, — основа планировщика запросов.
Когда вы запускаете ANALYZE, Postgres строит две структуры для каждой колонки. Именно на них в первую очередь смотрит планировщик, когда оценивает, сколько строк вернёт WHERE.

Ниже примеры из таблицы с HTTP-запросами. Такой набор данных удобно использовать, потому что там есть разные типы значений, которые легко представить.
Список наиболее частых значений (MCV)

Если самая сложная задача в компьютерных науках — кеширование и нейминг, то список most common values заслуживает место в зале славы за удачное название.

Это самые частые значения колонки и их точные частоты:

most_common_vals  = {GET, POST, PUT, DELETE, PATCH}
most_common_freqs = {0.70, 0.20, 0.05, 0.03, 0.02}

Здесь это HTTP-методы, поэтому набор значений ограничен спецификацией.
Для WHERE method = 'GET' планировщик напрямую читает 0.70 из списка.
70% от 200 000 строк = ожидаемые 140 000 строк.
Гистограмма с бакетами равной высоты

Для значений, которых нет в MCV-списке, Postgres строит equi-height buckets. Ниже пример гистограммы для колонки со временем ответа в миллисекундах:

histogram_bounds = {83, 88, 95, 107, 132, 166, 195, 245, 362, 554, 965, 2622164}

Каждый бакет содержит примерно одинаковое количество строк. Бакет [245, 362] содержит примерно столько же строк, сколько [83, 88].

За счёт фиксированного количества строк диапазон значений становится переменным. Это упрощает оценку количества строк.
NULL-гистограммы

Когда все уникальные значения помещаются в MCV-список, histogram_bounds становится NULL.
У колонки method всего 5 значений. Все они попадают в MCV-список, поэтому гистограмма не нужна.

Зачем нужны две структуры?
MCV даёт точные частоты для популярных значений, а гистограмма покрывает длинный хвост — редкие или непрерывные значения через приближение. Вместе они описывают полное распределение без хранения каждого значения отдельно.

Чтобы посмотреть статистику для таблицы и колонки:

SELECT 
  most_common_vals, 
  most_common_freqs, 
  histogram_bounds
FROM pg_stats
WHERE tablename = 'requests' 
  AND attname = 'status_code';

👉 @SQLPortal