Экосистема PostgreSQL славится своей фантастической расширяемостью: пока другие СУБД требуют годами ждать мажорных версий ради одной фичи, сообщество Postgres решает сложные инженерные задачи через специализированные модули. За последние дни состоялось сразу три заметных релиза, которые закрывают давние боли DBA и бэкендеров: проверка индексов без нагрузки на диск, честный замер перцентилей задержек и быстрая синхронизация агрегатов. Давай разберём каждую новинку.
HypoPG 1.4.4
Создание индекса на таблице в сотни гигабайт — это всегда стресс. Даже с флагом CONCURRENTLY построение дерева нагружает диск операциями ввода-вывода и утилизирует CPU. А самое обидное — когда после ожидания выясняется, что планировщик EXPLAIN просто игнорирует новенький индекс, предпочитая Sequential Scan, и дисковое пространство было потрачено зря.
Эту проблему решает открытое расширение HypoPG 1.4.4 (детали в официальном анонсе). Модуль вводит виртуальные индексы: они существуют только в памяти текущего сеанса и не создают файлов на диске.
-- Подключаем расширение в сессии
CREATE EXTENSION IF NOT EXISTS hypopg;
-- Создаем гипотетический индекс за доли миллисекунды
SELECT * FROM hypopg_create_index(
'CREATE INDEX ON orders (user_id, created_at)'
);
-- Проверяем план: оптимизатор видит виртуальный индекс!
EXPLAIN SELECT * FROM orders
WHERE user_id = 42 AND created_at >= NOW() - INTERVAL '7 days';
-- Сбрасываем виртуальные индексы
SELECT hypopg_reset();
В версии 1.4.4 авторы обновили внутренние вызовы планировщика под ветки PostgreSQL 16–18, оптимизировали расчёт селективности и устранили утечки памяти в длинных транзакциях.
pg_hdr_histogram 1.0.0
Когда мы анализируем производительность базы через pg_stat_statements, мы обычно смотрим на среднее время ответа (mean_exec_time). Но среднее значение в распределённых системах обманчиво: девяносто девять запросов отработают за миллисекунду, а сотый зависнет на десять секунд из-за блокировки. В среднем всё красиво, но реальный пользователь видит бесконечный спиннер.
Для честного мониторинга нужны перцентили (p95, p99). Однако сбор всех задержек каждого запроса быстро съедает память. Расширение pg_hdr_histogram 1.0.0 от Алексея Лесовского (см. анонс релиза) переносит в Postgres проверенный алгоритм HdrHistogram. Он сжимает гистограмму задержек в компактный буфер фиксированного размера с точностью до 3–5 значащих цифр:
-- Активация расширения и выборка перцентилей
CREATE EXTENSION IF NOT EXISTS pg_hdr_histogram;
SELECT
hdr_percentile(hist, 0.50) AS p50_ms,
hdr_percentile(hist, 0.95) AS p95_ms,
hdr_percentile(hist, 0.99) AS p99_ms
FROM query_performance_log;
Стабильный релиз 1.0.0 стабилизировал бинарный формат хранения, подтвердил совместимость с PostgreSQL 17 и ускорил агрегацию гистограмм между параллельными процессами.
pg_ivm 1.17
Материализованные представления (MATERIALIZED VIEW) отлично предрассчитывают тяжелые аналитические отчеты. Но у классического PostgreSQL команда REFRESH MATERIALIZED VIEW полностью пересчитывает представление с нуля, блокируя чтение и нагружая дисковый ввод-вывод.
Расширение pg_ivm 1.17 (Incremental View Maintenance, см. анонс проекта) реализует математический механизм инкрементального обновления: при изменении базовых таблиц пересчитывается только изменившаяся дельта данных!
-- Создание инкрементально обновляемого представления
CREATE EXTENSION IF NOT EXISTS pg_ivm;
SELECT create_immv(
'daily_sales_summary',
'SELECT department_id, COUNT(*) AS total_orders, SUM(amount) AS total_revenue
FROM orders GROUP BY department_id'
);
Теперь каждая операция INSERT в orders прозрачно обновляет счётчики в daily_sales_summary за доли миллисекунды. В обновлении 1.17 улучшена совместимость с веткой PostgreSQL 18 devel и оптимизированы триггеры отслеживания дельт. Если ты интересуешься развитием этой технологии, посмотри наш предыдущий материал про расширения PostgreSQL под ветку 19 и pg_ivm.
Все три расширения показывают зрелость экосистемы Postgres: ты можешь безопасно проверять индексы, снимать честную телеметрию и ускорять витрины прямо в СУБД без внешних костылей.