На апрельской конференции PG BootCamp 2025 в Екатеринбурге был представлен доклад Артёма Бугаенко о том, как сделать статистику Postgres более детализированной, не повышая DST. Однако если посмотреть на доклад под немного другим углом, то ему отлично подошло бы название «Пример создания патча для PostgreSQL». Примеры правки логики планировщика есть во многих патчах, но объяснение того, куда и какой код нужно вставлять в многочисленные файлы исходного кода PostgreSQL, встречается нечасто. Можно встретить примеры описания того, как добавить параметры конфигурации, а вот пример того, как добавить опцию в команду SQL, найти подчас затруднительно. Поэтому если вам требуется добавить в какую-либо команду свою опцию, можно использовать статью, доклад и предложенный докладчиком патч как руководство.

В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.

Типы данных PostgreSQL для работы с вещественными числами:

1) float4, синоним real, синоним float(1..24)

2) float8, синоним float, синоним double precision, синоним float(25..53)

3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.

Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.

Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.

float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:

В статье обзор пяти докладов прошедшей в апреле 2025 года конференции PgBootcamp. Даже на тех конференциях, которые я посещал, мне было бы интересно почитать обзор докладов, но я их не встречал. Иногда можно найти статью к докладу, но для большинства докладов на конференциях такого формата нет. По какой-то причине, обзоры докладов с конференций - редкость. Я решил написать обзор, возможно он окажется полезен.

Доклады конференции PgBootcamp недавно выложили в общий доступ и их можно скачать и посмотреть.

 Введение

Доклады конференций полезны тем, что содержат описание того, что актуально при работе с PostgreSQL. Организаторы выбирают наиболее интересные доклады и не пропускают то, что уже всем известно.

О конференции PgConf я знал давно, а о конференции PgBootcamp я узнал год назад. За это время прошли три конференции: в Казани, Минске и Екатеринбурге. Архив докладов есть на сайте pgbootcamp.ru (регистрироваться на сайте не нужно, в "Программе" - список докладов, внизу каждого доклада ссылка на видеозапись доклада).

Перед очередной конференцией можно бесплатно зарегистрироваться онлайн и оффлайн, она однодневная и проходит параллельно в двух залах. Регистрация на конференции полезна тем, что, что присылается ссылка на трансляцию и запись можно просматривать во время и сразу после окончания конференции. Без регистрации доклады становятся доступны только через 2-3 недели.

Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющих файлах и изменения их значений передаются через журнал (WAL) на реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.

Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

В статье визуализируется структура индекса и показывается, как меняется структура индекса типа btree в PostgreSQL. Это полезно для понимания, как выглядят индексы btree. Также рассматривается FILLFACTOR и пример исследования структуры индекса в целях определения, как перераспределяются индексные записи при включении в структуру индекса новых блоков (страниц). Создадим простую таблицу, индекс, вставим три строки:

На PgConf 2025 было три зала, в которых параллельно шли доклады. Поэтому охватить своим присутствием все доклады не представлялось возможным. В часть залов было не попасть, так как толпа участников толпилась на входе. Такое произошло и с докладом Михаила Жилина "Как PostgreSQL может сделать больно, когда не ожидаешь". В докладе описывалось 6 актуальных проблем. Проблема "#1: Глобальные счетчики" затрагивает почти все приложения, обновляющие строки в таблицах баз данных PostgreSQL. В этой статье рассматривают детали проблемы.

Закончилось основное событие года в мире PostgreSQL - PgConf 2025. В статье рассматривается патч, который ускоряет закрытие месяца в 1С-ERP в 10 раз, что довольно значительно. Патч был анонсировано в докладе "Быстрое закрытие месяца в 1С:ERP на PostgreSQL" или "Закрывай месяц в 1С ERP на PostgreSQL быстро и незаметно".

С 1С:ERP я не знаком, но знаю, что для 1С выпускаются специальные сборки PostgreSQL. Наполнившись решимостью узнать, что в этом 1С происходит я пожертвовал докладом про карту видимости, который шёл параллельно и не пожалел.

Я узнал, что в 1С никто ничего не делает, кроме как месяца закрывают и больше никого ничего не интересует, а также то, что по статистике пользователи приложения 1С:ERP делают что-либо, в среднем, раз в 20 минут. "Закрытие месяца" - набор расчетов и действий, которые могут выполняться часами. При этом с первого раза месяц обычно не закрывается, так как обнаруживаются ошибки учёта, которые должны быть исправлены и закрытие месяца повторяется заново. И так несколько раз. В докладе осветили нюансы установки границы итогов, удобство использования клонов кластера баз данных, описали причины проблем.

Основная интрига доклада была в том, что "секретный патч Фёдора Сигаева" ускоряет закрытие месяца в 10 раз (на порядок!). Не каждый день встретишь ускорение на порядок.

Порядок столбцов в таблицах влияет на компактность и производительность. При небольшом числе строк на это не обращают внимание. Если в таблицах хранится много строк, то даже небольшое уменьшение объема хранения может быть полезно. У столбцов есть оптимальный  порядок и менее оптимальные, которые отличаются размером, который используют строки при физическом хранении. Причина того, что переставив столбцы строки в таблице с теми же самыми данными, меняют размер в выравнивании (aligning) и заполнении нулями (padding). В блоке данных выравниваются все структуры: заголовки, поля строк и целиком сами строки.

На 64-разраядных операционных системах, длина любой строки и заголовка строки  выравниваются по 8 байт. То есть если строка занимает 28 байт, то физически она займёт 32 байта. В конец строки будут добавлены пустые байты. Поля выравниваются сложнее - по 4,8, 16 байт. В статье рассматривается перестановка столбцов на примере демонстрационной базы.

В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.

Если с данными (строками таблиц) работает одна сессия в базе данных, то разницы между уровнями изоляции транзакций нет, так как нет транзакций, от которых нужно изолироваться. Если есть несколько транзакций, которые пересекаются во времени, то нужно обращать внимание на то, что параллельно с теми же данными  работают другие транзакции. Другими  словами, учитывать особенности (феномены, аномалии) "конкурентного доступа".

В представлении pg_locks есть столбец fastpath, который означает, что блокировка получена по быстрому пути. В документации быстрый путь блокирования описан коротко. В статье рассматривается быстрый путь блокирования и чем он лучше обычного пути.

РostgreSQL автоматически обнаруживает взаимоблокировки. В статье рассматривается процедура обнаружения взаимоблокировок, трудоёмкость процедуры обнаружения, причины, по которым параметр конфигурации log_lock_waits зависит от параметра deadlock_timeout и что влияет на выбор его значения. Приводится пример, как использование select for update может приводить к взаимоблокировкам и как взаимоблокировки влияют на метрики pgbench.

Подпрограммы (функции и процедуры) со свойством SECURITY DEFINER выполняются с правами владельца. Это даёт возможность непривилегированному пользователю выполнить маскировку объектов, к которым относятся не только таблицы, но и подпрограммы и выполнить команду с правами владельца подпрограммы. Если владелец является суперпользователем, то можно выполнить любую команду с правами суперпользователя. В статье рассматривается, как выполнить маскировку функции и как создавать безопасные подпрограммы.

В статье рассматривается, сколько места занимают поля с пустыми значениями и стоит ли их использовать с точки зрения экономии места под хранение строк. В статье приведены расчёты и команды для самостоятельного повторения. Примеры полезны, чтобы понять, как в блоках хранятся строки с пустыми значениями. Для практического применения в конце статьи приведены результаты

Если экземпляр PostgreSQL был некорректно остановлен, то перед восстановлением файлов выполняется синхронизаций всех файлов кластера. Способ синхронизации определяется параметром конфигурации recovery_init_sync_method. В статье рассматривается, как ускорить запуск экземпляра и резервирование, если в директории PGDATA много файлов.

Из ролика "Реальный собес на бекенд программиста": "А знаешь что-нибудь про горизонт событий транзакции? Знаю про чёрные дыры, а вот про транзакции не очень. Ну расскажи про чёрные дыры тогда. Вкратце."
По умолчанию утилита pgbench запускает тест "TPC-B (sort of)" и используется для быстрой оценки производительности PostgreSQL. Горизонт удерживается на время выполнения любого запроса или транзакции. В статье рассматривается насколько удержание горизонта базы данных (vacuum cleanup horizon) уменьшает прозводительность (например, значение tps тестов). Также приводится запрос для мониторинга горизонта баз данных и параметры, которые используются для защиты от долгих транзакций и запросов.

При создании индексов типа btree в PostgreSQL есть опции DESC и NULLS FIRST. В статье рассматривается как эти опции влияют на производительность и размер btree-индексов PostgreSQL.

По умолчанию индекс строится в возрастающем порядке (ASC), то есть в дереве индекса "слева" меньшие значения, "справа" большие. При создании индекса можно указать обратный порядок: DESC. Свойство ASC и DESC при создании индекса не влияет на эффективность использования индекса планировщиком (ORDER BY ASC или DESC).

При выполнении тестов периодически сталкивался с неожиданными изменениями результатов тестов после рестарта linux и при обновлении версии linux. Причиной оказался источник времени. В статье рассмотрен как влияет источник времени на выполнение команды explain analyze

У последовательностей есть параметр cache, который определяет сколько значений из последовательности будет кэшировать серверный процесс в своей локальной памяти для будущих вставок в течение сессии. Последовательности используются первичными и уникальными ключами. По умолчанию значения последовательностей не кэшируются. Кэширование может снизить произвдительность и сделать структуру индекса не оптимальной.

Быстрый путь вставки в индексы

В PostgreSQL есть оптимизация вставки в индекс типа btree, позволяющая не спускаться с корня дерева индекса. Серверный процесс, который выполнил вставку в правый листовой блок, запоминает ссылку на него и при последующей вставке, если новое значение больше предыдущего (или пусто) и не проходит путь от корня до листового блока. Оптимизация используется при числе уровней в индексе начиная со второго (макрос BTREE_FASTPATH_MIN_LEVEL).

Если строка не помещается в блок (страницу), то в PostgreSQL применяется техника выноса полей в отдельную таблицу, называемую TOAST-таблица. Техника выноса и хранения называется TOAST (The Oversized-Attribute Storage Technique, техника хранения атрибутов большого размера). В статье достаточно детально рассматривается алгоритм работы TOAST. Знание алгорима и его граничные значения полезно, чтобы понимать каким образом хранятся данные в таблицах.