PGConf.Russia 2022

Я пересмотрел за жизнь много всякого кода, и очень часто встречал некоторый разнобой в обработке дат и времени: то у сторон не сходились отчеты за месяц, то суточные отчеты получались разные в Москве и Сан-Франциско, то еще чего-нибудь в таком же роде. Это не сказать чтобы сильно страшно, но довольно утомительно. Причина такого рода проблем всегда была связана с неаккуратной обработкой дат и времени. Тому, как этого можно постараться избежать, и посвящен мой доклад.

В докладе будет рассказано о проекте миграции учетной системы, отвечающей за финансовые операции ФГУП «Госкорпорация по ОрВД» в части взимания аэронавигационных сборов за использование воздушного пространства с СУБД Oracle на СУБД Postgres Pro.

В докладе расскажу об инфраструктуре PostgreSQL в Ozon: * какой тюнинг виртуальных машин (KVM) мы делаем * какую систему контроля версий мы создали * какие драйвера мы делаем и как это связано с отказоустойчивостью и балансировкой * как мы проводим обновление параметров виртуальных машин без остановки

Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.