Зачем еще 64-битные значения?
Когда PostgreSQL только появлялся, значения идентификатора транзакции были выбраны 32х-битными. В то время это казалось запредельным числом - кто в здравом уме будет проводить 4 миллиарда транзакций? Но развитие техники привело к тому, что появились инстансы, где транзакции подбирались к этому пределу. Сообщество разработчиков ответило на это возможностью "оборота" счетчика транзакций (известный как wraparound). Но технический прогресс и рост количества данных поставили PostgreSQL перед новыми вызовами. В докладе я попытаюсь рассказать об этих вызовах, о том, как их можно преодолеть с помощью повышения разрядности счетчика, к каким следствиям это приведет и почему это надо делать сейчас, и почему это не было сделано раньше.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
45 мин
Сергей Пронин Percona Manager, Technical Product ManagementDisaster Recovery PostgreSQL в Kubernetes
Запуск PostgreSQL в Kubernetes становится привычным делом с распространением операторов. В этом докладе расскажем про запуск отказоустойчивого PostgreSQL кластера в Kubernetes с помощью оператора, покажем, как подготовиться к падению дата центра и запуску hot-standby кластера.
-
45 мин
Брюс Момжиан EnterpriseDB Senior Database ArchitectPostgres и вызовы будущего
На протяжении нескольких десятков лет Postgres остаётся динамично развивающимся проектом. Вероятно, его популярность сохранится и в последующих десятилетиях. Тем не менее, как и в случае с любым другим сложным процессом, перед СУБД PostgreSQL появляются вызовы. В настоящем докладе мы исследуем вызовы будущего, которые могут помешать росту популярности Postgres - технические, проектные, конкурентные. Исследуя эти проблемы сегодня, мы сможем избежать их последствий в будущем.
-
22 минВВиталий Богданов АО «Байкал Электроникс» Директор по развитию
-
22 мин
Никита Дрей OT-OIL Руководитель группыОсобенности миграции ECM платформы на PostgreSQL
Доклад раскроет процесс и особенности проекта миграции корпоративной ECM платформы "ЭЛЬДОКА" с ORACLE на PostgreSQL: как был обеспечен объектно-ролевой доступ к данным, какого функционала было недостаточно в "свободной версии", как была организована работа с пространственными данными и как меняли подход в хранении файлового контента. Поделимся опытом, как сэкономили время/ресурсы, обеспечили репликацию данных между узлами и какие результаты в итоге были получены по производительности.