20 – 21 июня 2022
PGConf.Russia 2022
PGConf.Russia 2022
PGConf.Russia – международная техническая конференция по открытой СУБД PostgreSQL, ежегодно собирающая более 700 разработчиков, администраторов баз данных и IT-менеджеров для обмена опытом и профессионального общения. В программе – мастер-классы и доклады в два потока в течение двух дней, блиц-доклады из зала, живое общение на кофе-брейках и фуршете.
Темы встречи
- PostgreSQL на переднем крае: высокие нагрузки, большие БД, отказоустойчивость
- Новое в PostgreSQL и вокруг: развитие PostgreSQL и его экосистемы
- PostgreSQL в реальных системах: архитектура, миграция, эксплуатация
- Использование PostgreSQL в платформе 1С
- PostgreSQL в геоинформационных системах (GIS)
Доклады
Архив докладов
-
Александр, Бычков ООО "Эльбрус-2000" Аналитик
Николай Глазков ООО "Эльбрус-2000" инженерВ докладе будет рассказано о проекте миграции учетной системы, отвечающей за финансовые операции ФГУП «Госкорпорация по ОрВД» в части взимания аэронавигационных сборов за использование воздушного пространства с СУБД Oracle на СУБД Postgres Pro.
-
Андрей Бородин Яндекс РазработчикЛет 7 назад я пришёл от разработки под Windows к непреодолимому желанию дописать некоторые части PostgreSQL. В этом докладе я бы хотел рассказать о деталях вещей, которые были мне не очевидны, когда я начал работать с исходным кодом, системой сборки и тестирования PG. Я собираюсь говорить о самых простых вопросах - рутинные задачи IDE, навигация, сборка и всё такое. И совсем не претендую на какой-то истинный путь. Возможно, что-то покажется совсем проблемами чайников :) Я был бы рад, если бы другие разработчики тоже поделились секретами своего разработческого быта. Можем устроить обсуждение grep vs IDE :)
-
Дмитрий Вагин Avito Lead EngineerМы ранее рассказывали про внутренне устройство Авито, где и как хранятся ваши объявления, как эти объявления попадают в поиск. За последние 3-4 года очень много изменилось в Авито, мы избавились от использования логической репликации, использования standby для читающей нагрузки, практически отказались от хранимых процедур, избавились от самописного failover решения, мигрировали все объявления в шардированную базу данных, практически "распилили" монолит и перешли на разработку в микросервисах. Расскажу о причинах такого развития, проблемах с которыми столкнулись, и текущем положении дел.
-
Павел Толмачев Postgres Professional Специалист образовательного отделаЧем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.
Фотографии
Архив фотографий