Управление планами запросов - новые возможности

Расскажем о новых возможностях и продвинутых техниках управления планами запросов (совместное использование AQO, sr_plan и pg_hint_plan)

Слон и Моська. Проблема фенсинга в кластерах PostgreSQL

Довольно часто в кластерных конфигурациях PostgreSQL можно встретить настройку, отвечающую за ввод отказавшего ведущего сервера обратно в кластер в качестве реплики. Утилита pg_rewind выполнит синхронизацию данных между двумя серверами. Она копирует изменения из WAL-файлов основного сервера, которые не применялись на отстающем сервере (бывшем мастере). Однако без механизма fencing существует риск потери данных, если оба сервера (старый мастер и новый мастер) активны одновременно и оба принимают изменения данных. Эта ситуация называется split-brain, возникновение ее катастрофично для целостности данных. Поговорим о том, как минимизировать риски потери данных, какие есть варианты fencing-а, какие практики стоит использовать и в каких ситуациях.

Миграция с Oracle APEX/Forms на Эльбрус e2k. Проблемы. Производительность

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

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

Планы выполнения в pg_stat_statements

Есть много opensource (и еще больше проприетарных) форков pg_stat_statements, которые позволяют смотреть планы выполнения запросов:

pg_stat_plans https://github.com/2ndQuadrant/pg_stat_plans
pg_store_plans https://github.com/ossc-db/pg_store_plans
pg_stat_monitor https://github.com/percona/pg_stat_monitor

Все они мне чем-то не подошли и я написал свое https://github.com/postgredients/pg_stat_query_plans. Расскажу что и как сделал, и что хотелось бы добавить в оригинальный pg_stat_statements, чтобы мое расширение было не нужно