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