PGConf.СПб 2025

Мы выросли в эпоху реляционных СУБД, ценя их строгость и предсказуемость. Но современные нагрузки требуют горизонтального масштабирования. Представьте: за привычным SQL-интерфейсом работает уже не single-instance Postgres, а распределённый кластер с множеством равноправных мастеров. К чему приведёт такой переход? Какие из реляционных практик и привычек, накопленных десятилетиями, будут полезны в распределённой среде, а какие превратятся в угрозу производительности? В этом докладе разберёмся, как эффективно использовать распределённую СУБД Shardman, избежав типичных ошибок. Будет интересно тем, кто уже выбрал Shardman в качестве текущей СУБД, кто только в процессе выбора и широкому кругу лиц, интересующемуся распределенными СУБД.

На мастер-классе покажем, как с помощью инструмента Конвертум автоматически переносить сложную бизнес-логику из Oracle PL/SQL и T-SQL (SQL Server) в PostgreSQL, включая Postgres Pro. Разберем наиболее частые и технически сложные примеры конвертации: • пакетов, • иерархических запросов, • PIVOT, • Функций для работы с XML и JSON. Обсудим возможности кастомизации Конвертум под специфику проекта, а также применения различных опций для повышения уровня автоматической конвертации. Проведем демонстрацию инструмента на реальных сценариях и поделимся планами развития Конвертум.

В этом долладе мы рассмотрим скорость работы 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 (...) может всё испортить — или наоборот, внезапно ускорить запрос.