Запрос тормозит, а EXPLAIN ANALYZE выдаёт простыню узлов, в которой непонятно, на чём остановиться. Postgres Professional выпустила бесплатную книгу «PostgreSQL 18. Оптимизация запросов» на основе курса QPT. Она объясняет, как планировщик оценивает кардинальность и стоимость, как читать планы и какие приёмы работают для OLTP и OLAP. Читать можно хоть в метро: результаты запросов уже вплетены в текст, терминал не нужен.

Все данные лежат на быстрых SSD, хотя заказы трёхлетней давности читают раз в квартал. Это значит, что вы платите за дорогую ёмкость там, где она не нужна. Разбираем, как в Postgres Pro Enterprise расширения pgpro_ilm и pgpro_usage сами переносят редко используемые секции, таблицы и индексы на дешёвые диски. Показываем правила, на что они реагируют и какие подводные камни есть у этого механизма.

Мы дошли до финала: 30 000 ВРМ, 4 NUMA-узла, сервер на 480 логических ядер и APDEX = 0,986 в конфигурации с асинхронной репликой. Но на последнем отрезке пути нас ждали сюрпризы. Один процесс Xorg загружал целое ядро и тормозил тонкие клиенты. INSERT на 15 строк висел больше 20 секунд из-за блокировок BufferMapping. Подключённая реплика заставила rphost съедать вдвое больше памяти и уронила кластер 1С. Рассказываем, как мы с этим справились и что вошло в Postgres Pro Enterprise for 1C 18.6.1.

Тест упал на пятом часу, на переходе с 16 800 до 21 000 ВРМ. Потом запрос, который выполнялся меньше секунды, вдруг стал занимать десятки секунд. После этого отчёт вместо 5 секунд начал строиться 800. Во второй части мы разбираем, как с этим справились: от LWLock:PgStatsHash и сбежавшего плана запроса до гигабитной сетевой карты и 3 миллионов файлов временных таблиц. В итоге на 21 000 ВРМ получили APDEX = 0,975.

Мы провели больше 100 запусков альтернативного теста 1С:ERP от «ИТ-Экспертизы» и дошли до APDEX = 0,986 на 30 000 виртуальных пользователей. Путь был непростым. На 15 000 ВРМ APDEX сначала упал до 0,704, и нам пришлось разбираться с загадочными ошибками PostgreSQL, штормом инвалидаций и перекосом нагрузки по NUMA-узлам. Рассказываем, что именно помогло.

Хижину на высоте 3 930 метров в Кыргызстане пришлось сделать шире, чем в чертежах. Причина простая: матрасы оказались на несколько сантиметров больше, чем рассчитывали. К этому моменту материалы уже лежали на леднике: их привёз вертолёт, а недостающее мы дотаскивали в рюкзаках. Я работаю в Postgres Professional и около двадцати лет хожу в горы. Сейчас вместе с друзьями строю здесь новую хижину для альпинистов. Пока мы утепляем стены и собираем электрику, на ней уже ночуют люди, а по ночам заглядывают куницы. Для них мы закрыли все щели, но куницы всё равно нашли путь.

Завершаем обзор мартовского коммитфеста 19-й версии. В четвертой и последней статье серии рассмотрим изменения, относящиеся к языку SQL и материалам курсов DEV1 и DEV2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2) – мы здесь 🙂

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Продолжаем обзор мартовского коммитфеста 19-й версии. В третьей статье серии рассмотрим изменения, относящиеся к материалам курсов DBA3 и DBS.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS) – мы здесь 🙂

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Продолжаем обзор мартовского коммитфеста 19-й версии. Во второй статье серии рассмотрим изменения, относящиеся к материалам курсов DBA1 и DBA2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2) – мы здесь 🙂

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Завершаем цикл статей с обзором изменений 19-й версии. Предыдущие статьи были посвящены первым четырем коммитфестам: 2025-07, 2025-09, 2025-11, 2026-01.

А сегодня начнем обзор мартовского коммитфеста 2026 года. Почему «начнем»? По опыту прошлых лет, мартовский обзор всегда очень объемный. Именно в последнем коммитфесте принимается большое число важных изменений. Обзор не только сложно подготовить, но и непросто дочитать до конца 🙂. Поэтому для 19-й версии он разбит на четыре статьи.

В первую статью вошли изменения, так или иначе связанные с оптимизацией запросов, — все, что можно отнести к нашему учебному курсу QPT. Вторая будет посвящена изменениям, которые больше относятся к курсам DBA1 и DBA2. Третья — к DBA3 и DBS. В четвертой будут рассмотрены новинки SQL, а также изменения, относящиеся к курсам DEV1 и DEV2.

Считается, что если fsync включён в конфиге — данные в безопасности. На практике это не гарантия, а всего лишь надежда: вызов может быть проигнорирован драйвером, виртуализацией или самой ОС, а СУБД при этом честно подтвердит COMMIT клиенту. Разбираем, как через несколько независимых проверок — от системных вызовов до жёсткой перезагрузки тестового стенда — узнать, действительно ли ваш WAL долетает до диска, а не только до кэша операционной системы.

Что, если индекс не нужно создавать вообще? Знакомимся с iHeap — альтернативным методом доступа к таблицам PostgreSQL, где BRIN-индексирование встроено «из коробки» и работает автоматически для всех подходящих столбцов.

Что делать, если WAL удалён, сервер убит kill -9, база после pg_resetwal не хочет открываться, а бизнес стоит уже сутки? Это не гипотетический вопрос, а реальный кейс с кластером PostgreSQL для 1С на 2,5 терабайта данных. Расскажем историю о том, как без бэкапов, без WAL-архивов и почти без надежды вытащили критичные данные 1С-инфобазы. А в конце — неожиданный поход в апстрим PostgreSQL с патчем для pg_dump.

PGW: A PGBACKREST INTERLUDE:

(Andreas Scherbaum, Jimmy Angelakos)

Andreas Scherbaum and Jimmy Angelakos presented a quantitative analysis of the PostgreSQL CommitFest process using data collected from the CommitFest application itself.

The talk showed how PostgreSQL development has scaled significantly over the years. In 2015, CommitFest handled 418 patches from 125 authors, while in 2025 it handled 885 patches from 272 authors — roughly doubling both patch volume and contributor count. However, reviewer and committer capacity has not scaled equally well. The speakers showed that 72.1% of “Needs Review” patches currently have no reviewer assigned, and 196 out of 331 active patches in the current CommitFest have zero reviewers.

Построение HA-кластера в PostgreSQL традиционно требует внешнего стека: Patroni, распределенного хранилища конфигураций и набора вспомогательных утилит. В СУБД Postgres Pro Standard и Enterprise отказоустойчивость реализована на уровне ядра: механизм BiHA берет на себя консенсус Raft, защиту от split-brain и перестроение топологии.

Разбираем, как устроена встроенная отказоустойчивость, как система автоматически выравнивает расхождения в WAL без ручного вмешательства DBA и в каких сценариях такой подход надежнее самосборного контура.

pgrust это СУБД или злая шутка?

Майкл Мэйлис (Michael Malis), житель Сан Франциско, основатель freshpaint‑io, работал в компании Heap — человек в мире Postgres не слишком известный, хотя давний пользователь. Он, скорее, из мира фанатов Rust и Common LISP. Он был бы возмутителем спокойствия Postgres‑сообщества — да чего там: ИТ‑сообщества — если б там сейчас было какое‑то спокойствие.

У него есть свой сайт — malisper.me. Там многое рассказано, хотя наиболее шустро новость разошлась с форумов — с рэддит: pgrust: Postgres rewritten from scratch in Rust, currently passing 34% of the Postgres test suite, или с ycombinator: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests. В рунете новость появилась на OpenNET.ru: pgrust — клон PostgreSQL на Rust, проходящий все регрессионные тесты.

18–21 ноября 2026 года в Непале пройдёт PGConf.Nepal 2026 — четвёртая PostgreSQL-конференция в стране. Предыдущие конференции состоялись в 2018, 2023 и в 2025 годах. В этом году конференция должна стать шире по составу участников, организаций и стран.

Мы продолжаем праздновать 30-летие PostgreSQL и публикуем перевод второй фундаментальной статьи о СУБД. Перевод первого манифеста можно прочесть в этом посте.

Утечка данных почти никогда не выглядит как взлом — чаще это тихий SELECT без LIMIT от роли, у которой и так есть доступ. Заметить такое штатными средствами PostgreSQL почти невозможно: аудита как отдельной подсистемы там нет, а есть лишь разрозненные логи, из которых расследование превращается в quest с grep. В этой статье — как с помощью pg_proaudit и pgpro-otel-collector превратить эту головную боль в один запрос на LogsQL.

Сессионные вычислители — залог успеха аналитики будущего

Всем привет, меня зовут Николай Голов. azathot Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.

[ Vertica+Anchor Modeling = запусти рост своей грибницы (Avito блог??, перед?? ней HP Vertica, проектирование хранилища данных, больших данных ]

- статья, 27 февраля

наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:

— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».

Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.

Как должна выглядеть база, в которой аналитикам действительно можно дать полную свободу? Представьте: каждый аналитик работает в своей персональной базе данных. Он видит актуальные данные в реальном времени, но физически не делит «железо» с соседом.

Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data: