PGConf.Pоссия 2026

Рассмотрю подходы (фактически — инструкции) к решению вопроса организации работы с текстом в ванильном Postgres в рамках чувствительности/не чувствительности регистра при обработке и поиске данных. Доклад будет полезен для разработчиков и тем кто планирует переход на Postgres особенно с платформ MS SQL

Классическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит «мелочь». Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой Иногда виновником оказываются «горячие блоки». Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком. В этом докладе я расскажу: 1. Как возникают «горячие блоки» и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть «под капот» базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.

В архитектуре «PostgreSQL для OLTP + ClickHouse для OLAP» команда неизбежно сталкивается с фрагментацией: разные подключения в BI, разные диалекты SQL, ручные JOIN между системами через ETL и дублирование витрин. В докладе разберём практический опыт EGAR по внедрению расширения pg_clickhouse — PostgreSQL extension/FDW, который позволяет выполнять аналитические запросы на ClickHouse прямо из PostgreSQL с поддержкой pushdown (WHERE/JOIN/AGG и др.) и прозрачным подключением для BI-инструментов. Покажу архитектуру, принципы pushdown, типовые сценарии (профиль компании, отрасли, регионы, скоринг), а также ограничения и «правила безопасного применения»  (как проверять pushdown через EXPLAIN/ANALYZE, как выбирать витрины, где эффект максимален). В результате — единая точка входа в данные и ускорение дашбордов с десятков секунд до нескольких секунд на больших объёмах.

На примере собственноручно созданного инструмента PGHist расскажу, как отслеживать изменения в таблицах PostgreSQL через автогенерацию триггеров и процедур. Универсальное решение обеспечивает: историю для пользователя, аудит для анализа проблем и версионирование для отчётов. Покажу ключевые приёмы (лайфхаки) — момент фиксации транзакции, читабельная генерация кода и данные «до/после» в DDL-триггерах.