PGConf.СПб 2025

В этом долладе мы рассмотрим скорость работы PostgreSQL с ключами различных типов: Int4, Int8, Numeric, Uuid, Text. Также, сравним скорость работы текстовых ключей при различных правилах сортировки (Collation) И в заключение - сравним скорость работы 1, 20, ... 100 столбца в одной и той же таблице.

- Поиск неоптимальных запросов - Управление планом запроса - Контроль над оптимизатором - Автоматическое выявление деградации производительности - Исправление проблем в реальном времени

До того как запрос попадёт к оптимизатору PostgreSQL, с ним происходит немало интересного — и полезного. В этом докладе мы разберём три небольшие, но весьма эффективные трансформации и улучшения, которые происходят ещё до запуска процесса генерации плана запроса, и которые напрямую влияют на выбор плана выполнения и производительность. 🔹 VALUES → ANY Запросы вида x IN (VALUES (...)) автоматически переписываются в форму x = ANY (ARRAY[...]). Зачем? Чтобы избежать ошибочных оценок кардинальности и избыточных JOIN-ов. 🔹 Тривиальные арифметические упрощения Выражения вроде x + 0, x * 1 или x - 0 — это не просто «визуальный шум». Без упрощения такие условия мешают оптимизатору распознать возможность использовать индекс. Простая алгебраическая трансформация может буквально превратить Seq Scan в Index Only Scan и сократить время выполнения в разы! 🔹 Кэширование подзапросов (Memoize) Когда коррелированные подзапросы вызываются много раз с одними и теми же параметрами, PostgreSQL теперь может запомнить их результат и переиспользовать, вместо того чтобы каждый раз выполнять заново. Это особенно полезно в Nested Loop-соединениях и в запросах с IN (SELECT ...). В докладе будут приведены реальные примеры запросов и EXPLAIN ANALYZE-сравнения с до и после таких трансформаций. Мы поговорим о механике этих фич, о том, когда они срабатывают, и какие условия нужны, чтобы они принесли максимальную пользу. Этот доклад будет полезен тем, кто хочет понимать, почему иногда "один лишний ноль" или VALUES (...) может всё испортить — или наоборот, внезапно ускорить запрос.

Планировщик PostgreSQL — мощный, но у него есть слабое место: он не всегда строит планы корректно. Мы покажем, как набор расширений из Postgres Pro помогает довести его до уровня «почти телепатии». AQE (Adaptive Query Execution) позволяет переоценивать стоимость на основе реальной кардинальности и перестраивать план на лету. pgpro_multiplan — кеширование и хранение нескольких готовых планов для одного запроса: движок сам выбирает оптимальный в зависимости от параметров. pgpro_planner — набор «умных трансформаций» до оптимизатора: он переписывает запрос так, чтобы избежать ошибочных оценок, избыточных JOIN-ов и Seq Scan-ов, а оптимизатор сразу видит более быстрый вариант выполнения. Разберём, как эти расширения взаимодействуют между собой и где они реально помогают на сложных запросах.