Другие доклады
-
22 мин
Татьяна Крупеня DBeaver Corp CEO
Сергей Ридер DBeaver Corp Технический директорКак ускорить загрузку данных в 10 000 раз?
Что может быть важнее скорости в вопросе загрузки данных в базу? Миграция данных одна из самых востребованных функций в DBeaver, поэтому вопрос производительности стоял для нас очень остро, причем не только в применении для PostgreSQL, но и для Greenplum, Redshift и других баз, основанных на Postgres. Мы готовы поделиться маленькими секретами, как ускорить загрузку данных в 10, 100, 1000 и даже 10 000 раз без всякой магии.
-
22 мин
Никита Дрей OT-OIL Руководитель группыОсобенности миграции ECM платформы на PostgreSQL
Доклад раскроет процесс и особенности проекта миграции корпоративной ECM платформы "ЭЛЬДОКА" с ORACLE на PostgreSQL: как был обеспечен объектно-ролевой доступ к данным, какого функционала было недостаточно в "свободной версии", как была организована работа с пространственными данными и как меняли подход в хранении файлового контента. Поделимся опытом, как сэкономили время/ресурсы, обеспечили репликацию данных между узлами и какие результаты в итоге были получены по производительности.
-
45 мин
Михаил Цветков Intel Технический директорPostgreSQL на новых процессорах Xeon и Optane Persistent Memory
Масштабируемые процессоры Intel® Xeon® третьего поколения - добавлены новые команды для ускорения DB: vector bit manipulation instructions для сжатия без потерь, векторные инструкции для ускорения протоколов типа TLS и SGX-анклавы для безопасного исполнения кода. И, конечно, новое поколение энергонезависимой памяти Intel® Optane™ 200 серии. Рассмотрим, что эти новые технологии и открытый инструментарий oneAPI могут дать проекту PostgreSQL.
-
22 мин
Федор Сигаев Postgres Professional технический директор, ведущий разработчик PostgreSQLЗачем еще 64-битные значения?
Когда PostgreSQL только появлялся, значения идентификатора транзакции были выбраны 32х-битными. В то время это казалось запредельным числом - кто в здравом уме будет проводить 4 миллиарда транзакций? Но развитие техники привело к тому, что появились инстансы, где транзакции подбирались к этому пределу. Сообщество разработчиков ответило на это возможностью "оборота" счетчика транзакций (известный как wraparound). Но технический прогресс и рост количества данных поставили PostgreSQL перед новыми вызовами. В докладе я попытаюсь рассказать об этих вызовах, о том, как их можно преодолеть с помощью повышения разрядности счетчика, к каким следствиям это приведет и почему это надо делать сейчас, и почему это не было сделано раньше.