PGConf.Russia 2024

В greenplum используется отличный от PostgreSQL подход для сбора статистики выполнения запросов: вместо pg_stat_statements - командный центр. Командный центр - отдельное приложение. А значит нет необходимости хранить статистику в разделяемой памяти. Но нужно отправлять ее отдельному процессу. Расскажу: - как мы его реализовали; - почему использование grpc в postgreSQL - плохая идея и с какими еще проблемами мы столкнулись; - какие хуки было бы неплохо добавить в postgreSQL; - как не тормозить на отправке данных; - какие новые возможности появляются у отдельного приложения.

Ни для кого не секрет, что объемы баз данных растут с невероятной скоростью. Мы хотим поделится опытом развертывания тестовых и dev-контуров СУБД больших размеров за несколько секунд. В докладе будут проблемы, с которыми мы столкнулись, наш тернистый путь к ZFS и разъяснение рабочей схемы, как же все-таки оно работает у нас, и как мы с этим живем. Будет интересно.

Расскажем об опыте миграции с Oracle Forms / Apex на платформу x86 Расскажем об опыте последующий миграции решений на Эльбрус e2k Расскажем об производительности / масштабируемости (БД/количестве пользователей)

На примере НПФ Корпорации "Ростех" / НПФ ПАО "Ростелеком"

В докладе представлен обобщённый опыт компании ЕДИНЫЙ ЦУПИС в вопросах оптимизации OLTP-запросов: • Как идентифицировать причины перегрузки сервера. • Какие настройки помогают улучшать планы и ускорять запросы, которые и так работают быстро. • Как лучше подготовить индексы и сами запросы. Также будут рассмотрены различные примеры деградации производительности из практики.