23 – 24 марта
PGConf.Pоссия 2026
PGConf.Pоссия 2026
PGConf.Россия — крупнейшая конференция по PostgreSQL в России и СНГ. Технические доклады, демонстрации решений для работы с СУБД, мастер-классы, а также нетворкинг и обмен опытом с сообществом. Ежегодно участие в PGConf.Россия принимают сотни специалистов, среди них: администраторы баз данных, архитекторы, разработчики и тестировщики, IT-менеджеры.
РЕГИСТРАЦИЯ НА МЕРОПРИЯТИЕ ЗАКОНЧЕНА.
Темы встречи
- Новости из мира PostgreSQL
- Мониторинг, отказоустойчивость и безопасность
- Облегченная миграция с Oracle, Microsoft SQL Server и других систем
- Оптимизация запросов
- Масштабируемость, шардирование и секционирование
- Искусственный интеллект в СУБД
- Совместимость PostgreSQL с другим ПО
Доклады
Архив докладов
-
Денис Гидин Postgres Professional Старший инженермастер-класс 180 минМастер-класс включает в себя теорию, демонстрацию и самостоятельные практические упражнения на виртуальной среде (170 минут) Слушатели узнают: - как найти неоптимальные запросы, выполняющиеся в СУБД в текущий момент - как вручную управлять планом запроса - как зафиксировать план запроса для использования в будущем - как настроить автоматическое адаптивное выполнения запросов по триггерам - как использовать адаптивную оптимизацию запросов на основе машинного обучения - о недавних изменениях в функционале
-
Дмитрий Ремизов ГНИВЦ АрхитекторРазнообразные проблемы (и решения) в больших производственных системах после переноса на PostgreSQL. Multi- и Sub- транзакции (детективная история). Типичные проблемы оптимизатора. Разница в преобразовании типов и т.д. и т.п.
-
Александра Бондарь Postgres Professional СпециалистКлассическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит «мелочь». Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой Иногда виновником оказываются «горячие блоки». Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком. В этом докладе я расскажу: 1. Как возникают «горячие блоки» и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть «под капот» базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.
-
Михаил Гилев Алтайский Государственный Технический Университет им. И.И. Ползунова СтудентПланировщик запросов является одним из самых сложных компонентов СУБД PostgreSQL, и, несмотря на его продуманную реализацию, на практике встречаются случаи построения неоптимальных планов. Причем подобные ситуации могут быть настолько нетривиальными, что без специальных инструментов исследования процесса перебора планов невозможно выяснить истинную причину проблемы. В докладе на реальных примерах проблемных запросов мы покажем, как использовать расширение extended_explain для выявления истинных причин выбора неоптимального плана.
Фотографии
Архив фотографий