В первой части был изложен основной тезис: pg_stat_statements считает, а не записывает. В ней было показано, как перемешивание queryid разбивает один логический запрос на множество строк, как зафиксированный при первом появлении текст «замораживает» ваши теги на каждый запрос и как усреднённые значения скрывают тот p99, который на самом деле заставляет вас просыпаться по ночам. Всё это касалось данных, которые расширение собирает, но искажает.
Параметр только для чтения, подобно block_size, — команда SHOW data_checksums сообщает, включены ли в кластере контрольные суммы страниц, и это единственное взаимодействие, которое предлагает данный GUC. Но, в отличие от block_size, у этого параметра тринадцатилетняя история, которая всё ещё пишется, и эта история и есть предмет данной статьи.
Большинство параметров стоимости планировщика связаны с моделированием оборудования — насколько дорого чтение случайной страницы, насколько дорог такт ЦП. cursor_tuple_fraction отличается. Он связан с моделированием вас: а именно, с предположением планировщика о том, какую часть результата курсора вы на самом деле собираетесь извлечь.
Расширение pg_stat_statements — если не первое, то одно из самых используемых в экосистеме PostgreSQL. Оно поставляется в составе contrib и практически не требует затрат на использование. Большинство из нас обращаются к нему, чтобы ответить на вопрос: что на самом деле делает база данных? Это действительно полезно. Вы можете использовать его, чтобы получить снимок того, что происходило в заданный интервал времени, и быстрее принять решение о том, что исправлять.
createrole_self_grant — небольшой, недавний (PostgreSQL 16) и почти невозможный для объяснения изолированно. Чтобы рассказать, что он делает, нам нужно поговорить о том, какой была система ролей до 16-й версии, какой она стала сейчас и почему произошли изменения. Этот параметр является одним из видимых артефактов довольно существенного пересмотра, и этот пересмотр интереснее самого параметра.
Мы делали всё правильно. План миграции был надёжным, команда опытной, и мы делали такое и раньше. Но где-то около полуночи кто-то из команды заметил нечто странное. Таблицы на стороне назначения неожиданно разрастались, потребляя сотни гигабайт, в то время как таблицы на исходной стороне спокойно занимали всего несколько мегабайт.
Что-то было серьёзно не так, и мы понятия не имели, что именно.
cpu_tuple_cost, cpu_index_tuple_cost и cpu_operator_cost — это три константы, которые планировщик использует для оценки стоимости запроса. Самое полезное, что можно знать о всех трёх — это то, что вам почти наверняка никогда не следует их менять. Остальная часть статьи объясняет, почему.
constraint_exclusion управляет трюком планировщика: когда таблица имеет ограничение CHECK, планировщик может сравнить это ограничение с условием WHERE вашего запроса и, если они противоречат друг другу, пропустить сканирование таблицы целиком.
Если вы не много экспериментировали с SQL Server 2022, вы может быть незнакомы с функциями DATE_BUCKET и DATETRUNC. Обе они полезны, когда дело доходит до агрегирования данных. Давайте рассмотрим каждую из этих функций на нескольких примерах.
DATE_BUCKET
Начнем с DATE_BUCKET. DATE_BUCKET дает вам возможность агрегировать данные на основе выбранного вами интервала. Допустим, мы имеем такой набор событий:
config_file сообщает серверу PostgreSQL, где находится postgresql.conf, что должно заставить вас на мгновение задуматься. Если сервер узнаёт, где находится его файл конфигурации, из параметра, а параметры берутся из файла конфигурации, как он вообще находит первый файл?
compute_query_id по умолчанию имеет значение auto, потому что разработчики PostgreSQL оказались в тупике. PostgreSQL 14 переместил вычисление идентификатора запроса в ядро сервера, чтобы всё, что нуждается в идентификаторе запроса — pg_stat_statements, pg_stat_activity, EXPLAIN и журналы, — могло использовать одно каноническое значение вместо того, чтобы в каждом случае изобретать своё. Это оставило вопрос о том, каким должно быть значение по умолчанию, и оба очевидных ответа были плохими. Вычислять идентификатор для всех — значит облагать каждый фоновый процесс хэшированием, которое ему, возможно, никогда не понадобится; не вычислять ни для кого — значит незаметно сломать все стеки мониторинга и руководства по настройке, которые предполагали наличие идентификаторов запросов. auto — это выход: вычислять идентификатор только тогда, когда кто-то, кому он нужен, запрашивает его.
Логическая репликация прошла долгий путь с момента её появления в PostgreSQL. Сейчас она применяется шире, чем когда-либо, обеспечивая обновления между версиями, мультирегиональные развёртывания и конвейеры аналитики в реальном времени. Однако значительные возможности для улучшения всё ещё остаются.
В этой статье мы покажем практические идеи по улучшению логической репликации PostgreSQL. Вы узнайте о производительности, исправлении ошибок, рефакторинге кода и улучшении функциональности подписчика.
Будут рассмотрены узкие места производительности, отсутствующие функции и тонкие ошибки — всё это ждёт своих исправителей, готовых погрузиться в код.
В этой статье мы делимся практическими уроками, которые мы извлекли из работы над логической репликацией PostgreSQL: на что обращать внимание, как тестировать и какие подводные камни ожидают на стороне издателя и подписчика. Независимо от того, новичок вы в контрибуции или опытный разработчик в поисках следующего проекта, мы надеемся, что это руководство даст вам полезный старт.
commit_timestamp_buffers — первый в алфавитном порядке из семи параметров, которые PostgreSQL 17 добавил для выполнения одной и той же задачи для семи различных кэшей, поэтому эта статья объясняет эту задачу, а остальная часть кластера параметров может остаться краткой.
commit_delay — это та единственная настройка, которая говорит групповой фиксации (group commit) PostgreSQL ждать более многочисленной группы. База данных уже сама группирует сбросы WAL: когда один фоновый процесс выполняет сброс WAL, другие, готовые к фиксации, выстраиваются за ним и присоединяются к тому же fsync. commit_delay заставляет процесс, инициирующий этот сброс, сделать паузу на заданное количество микросекунд перед его началом, в предположении, что за время паузы подойдут ещё несколько транзакций и присоединятся к группе. commit_siblings — это сторожевой параметр, который решает, стоит ли вообще делать эту паузу.
