Практические примеры по оптимизации запросов в PostgeSQL

Я думаю, что каждый администратор баз данных в своей работе сталкиваемся с "тяжелыми" запросами. И возникает вопрос, а можно ли вообще ускорить работу этого запроса? Может быть, даже и оптимизировать такие запросы невозможно? Или время на переработку этого запроса будет существенно больше, чем выигрыш от производительности этого запроса. В своем докладе я рассмотрю несколько подходов к ускорению запросов и на практических примерах покажу оптимизации, которые использую в своей работе.

Поддержка пакетов Oracle (packages) в СУБД Postgres Pro 15 Enterprise

Одной из основных проблем при миграции с СУБД Oracle на PostgreSQL, являются пакеты PL/SQL.

В СУБД PostgreSQL отсутствует такой функционал - это приводит к необходимости переписывания (вплоть до его редизайна!) кода Oracle PL/SQL на PL/pgSQL.

В новой версии своего флагманского дистрибутива Postgres Pro 15 Enterpise компания Postgres Pro добавила поддержку функциональности пакетов: расширен синтаксис PL/pgSQL и добавлены новые механизмы в среду выполнения хранимых процедур. В докладе речь пойдет идет о поддержке функциональности пакетов в Postgres Pro 15 Enterpise: - группировка типов переменных процедур и функций в пакет; - поддержка секции инициализации пакетов; - поддержка глобальных переменных пакета доступных в течении всей "жизни" сессии.

Также в докладе будут рассмотрены особенности миграции пакетов из Oracle в СУБД Postgres Pro Enterprise.

Гетерогенная распределенная система – как способ безопасного перехода с MSSQL Server на PostgreSQL, а также снижения санкционных рисков

Данный доклад предназначен в первую очередь для компаний, а точнее для их ИТ служб, эксплуатирующих российские системы 1С 8.х и имеющих возможность работать как на СУБД MSSQL Server, так и PostgreSQL. Мы живем в уникальное время, когда наличие в своем арсенале гетерогенной ИТ-системы (системы, имеющей распределенную архитектуру, где каждый экземпляр базы данных работает под управлением разных СУБД и/или имеет разную структуру данных) является оправданным как с экономической точки зрения, так и с учетом возможных рисков. С одной стороны, мы храним данные и пользуемся СУБД с предсказуемым поведением и открытым кодом, независимо от политической обстановки. С другой стороны, мы при таком подходе пользуемся всеми преимуществами (в первую очередь производительности) мощной СУБД поддерживаемой крупнейшим вендором пускай и недружественного нам государства. Именно сейчас необходимо оценивать риски с необходимым уровнем паранойи. Возможно ведь, что данные могут быть испорчены не только на уровне логики хранения, но и методом дополнительного «скрытого» вызова конструкций типа Delete/Update на уровне движка СУБД. Поэтому сейчас актуальным становится не только мониторинг производительности ИТ-системы, но и аудит данных и их своевременная сохранность. Необходимо реализовывать процедуры верификации данных, необходимо реализовывать процедуры закрытия периодов, процедуры отказоустойчивого хранения. И соответственно, предусматривать в процедурах восстановления данных различные модели угроз. В докладе представлены варианты противодействия подобным угрозам и сценарии максимально бесшовного перехода больших баз данных на PostgeSQL, ведь именно для подобных баз проблема перевода на новую СУБД стоит особо остро.

Кластер Corosync-Pacemaker. Работа над ошибками

Расскажу о частых ошибках при настройке отказоустойчивого кластера Corosync-Pacemaker. Зачастую эти ошибки приводят к фатальным последствиям, и как следствие - к отказу от выбранного решения в пользу других. Хотите рецепт "правильного" кластера?