Автор: Christophe Pettus, All Your GUCs in a Row: createrole_self_grant
Большинство параметров стоимости планировщика связаны с моделированием оборудования — насколько дорого чтение случайной страницы, насколько дорог такт ЦП. cursor_tuple_fraction отличается. Он связан с моделированием вас: а именно, с предположением планировщика о том, какую часть результата курсора вы на самом деле собираетесь извлечь.
Автор: Radim Marek, pg_stat_statements: everything it tells you
Расширение pg_stat_statements — если не первое, то одно из самых используемых в экосистеме PostgreSQL. Оно поставляется в составе contrib и практически не требует затрат на использование. Большинство из нас обращаются к нему, чтобы ответить на вопрос: что на самом деле делает база данных? Это действительно полезно. Вы можете использовать его, чтобы получить снимок того, что происходило в заданный интервал времени, и быстрее принять решение о том, что исправлять.
Автор: Christophe Pettus, All Your GUCs in a Row: createrole_self_grant
createrole_self_grant — небольшой, недавний (PostgreSQL 16) и почти невозможный для объяснения изолированно. Чтобы рассказать, что он делает, нам нужно поговорить о том, какой была система ролей до 16-й версии, какой она стала сейчас и почему произошли изменения. Этот параметр является одним из видимых артефактов довольно существенного пересмотра, и этот пересмотр интереснее самого параметра.
Автор: Semab Tariq, The Night Our Tables Wouldn’t Stop Growing
Мы делали всё правильно. План миграции был надёжным, команда опытной, и мы делали такое и раньше. Но где-то около полуночи кто-то из команды заметил нечто странное. Таблицы на стороне назначения неожиданно разрастались, потребляя сотни гигабайт, в то время как таблицы на исходной стороне спокойно занимали всего несколько мегабайт.
Что-то было серьёзно не так, и мы понятия не имели, что именно.
Continue reading "Ночь, когда наши таблицы не переставали расти"Автор: Christophe Pettus, All Your GUCs in a Row: cpu_index_tuple_cost, cpu_operator_cost и cpu_tuple_cost
cpu_tuple_cost, cpu_index_tuple_cost и cpu_operator_cost — это три константы, которые планировщик использует для оценки стоимости запроса. Самое полезное, что можно знать о всех трёх — это то, что вам почти наверняка никогда не следует их менять. Остальная часть статьи объясняет, почему.
Автор: Christophe Pettus, All Your GUCs in a Row: constraint_exclusion
constraint_exclusion управляет трюком планировщика: когда таблица имеет ограничение CHECK, планировщик может сравнить это ограничение с условием WHERE вашего запроса и, если они противоречат друг другу, пропустить сканирование таблицы целиком.
Автор: Christophe Pettus, All Your GUCs in a Row: config_file
config_file сообщает серверу PostgreSQL, где находится postgresql.conf, что должно заставить вас на мгновение задуматься. Если сервер узнаёт, где находится его файл конфигурации, из параметра, а параметры берутся из файла конфигурации, как он вообще находит первый файл?
Автор: Christophe Pettus, All Your GUCs in a Row: compute_query_id
compute_query_id по умолчанию имеет значение auto, потому что разработчики PostgreSQL оказались в тупике. PostgreSQL 14 переместил вычисление идентификатора запроса в ядро сервера, чтобы всё, что нуждается в идентификаторе запроса — pg_stat_statements, pg_stat_activity, EXPLAIN и журналы, — могло использовать одно каноническое значение вместо того, чтобы в каждом случае изобретать своё. Это оставило вопрос о том, каким должно быть значение по умолчанию, и оба очевидных ответа были плохими. Вычислять идентификатор для всех — значит облагать каждый фоновый процесс хэшированием, которое ему, возможно, никогда не понадобится; не вычислять ни для кого — значит незаметно сломать все стеки мониторинга и руководства по настройке, которые предполагали наличие идентификаторов запросов. auto — это выход: вычислять идентификатор только тогда, когда кто-то, кому он нужен, запрашивает его.
Авторы: Zhijie Hou, Hayato Kuroda, How to hack the Publisher
Логическая репликация прошла долгий путь с момента её появления в PostgreSQL. Сейчас она применяется шире, чем когда-либо, обеспечивая обновления между версиями, мультирегиональные развёртывания и конвейеры аналитики в реальном времени. Однако значительные возможности для улучшения всё ещё остаются.
В этой статье мы покажем практические идеи по улучшению логической репликации PostgreSQL. Вы узнайте о производительности, исправлении ошибок, рефакторинге кода и улучшении функциональности подписчика.
Будут рассмотрены узкие места производительности, отсутствующие функции и тонкие ошибки — всё это ждёт своих исправителей, готовых погрузиться в код.
В этой статье мы делимся практическими уроками, которые мы извлекли из работы над логической репликацией PostgreSQL: на что обращать внимание, как тестировать и какие подводные камни ожидают на стороне издателя и подписчика. Независимо от того, новичок вы в контрибуции или опытный разработчик в поисках следующего проекта, мы надеемся, что это руководство даст вам полезный старт.
Continue reading "Как хакнуть издателя в логической репликацмм"Автор: Christophe Pettus, All Your GUCs in a Row: commit_timestamp_buffers
commit_timestamp_buffers — первый в алфавитном порядке из семи параметров, которые PostgreSQL 17 добавил для выполнения одной и той же задачи для семи различных кэшей, поэтому эта статья объясняет эту задачу, а остальная часть кластера параметров может остаться краткой.
Автор: Christophe Pettus, All Your GUCs in a Row: commit_delay and commit_siblings
commit_delay — это та единственная настройка, которая говорит групповой фиксации (group commit) PostgreSQL ждать более многочисленной группы. База данных уже сама группирует сбросы WAL: когда один фоновый процесс выполняет сброс WAL, другие, готовые к фиксации, выстраиваются за ним и присоединяются к тому же fsync. commit_delay заставляет процесс, инициирующий этот сброс, сделать паузу на заданное количество микросекунд перед его началом, в предположении, что за время паузы подойдут ещё несколько транзакций и присоединятся к группе. commit_siblings — это сторожевой параметр, который решает, стоит ли вообще делать эту паузу.
Автор: Christophe Pettus, All Your GUCs in a Row: cluster_name
cluster_name выглядит как косметический параметр: метка, которая отображается в выводе ps, чтобы вы могли различать свои три экземпляра Postgres. На первичном сервере это всё, что он делает. На резервном сервере (standby) он может незаметно стать именем, которое первичный сервер использует, чтобы определить, удовлетворена ли синхронная репликация, — это гораздо более серьёзная задача для параметра, который большинство людей устанавливают и забывают.
Автор: Andrei Lepikhov, EXPLAIN Prettier, or Post-Processing Query Plans in Postgres
Эта история началась с книги, подаренной коллегой. Читая книгу Джимми Ангелакоса «PostgreSQL Mistakes and How to Avoid Them», я осознал одну вещь, которая давно меня беспокоила: в Postgres команда EXPLAIN выдаёт слишком много информации. Примеры, которые авторы обычно приводят при обсуждении различных аспектов систем баз данных, усложняют анализ рассматриваемой проблемы и отвлекают читателя. Так родилась идея пост-обработки вывода EXPLAIN — чтобы сделать планы запросов более читаемыми и сфокусированными на проблеме.
Автор: Christophe Pettus, All Your GUCs in a Row: client_min_messages
client_min_messages управляет тем, сколько сервер говорит вам: сообщения, которые возвращаются по сети в ваш сеанс. Его постоянно путают с параметром, управляющим тем, что сервер записывает в свой собственный журнал. Это разные задачи с разными параметрами, и путаница — это то место, где начинается большинство проблем.
Автор: Christophe Pettus, All Your GUCs in a Row: client_encoding
client_encoding объявляет, в какой кодировке символов говорит клиент. Сервер использует этот параметр для преобразования между своей внутренней кодировкой (устанавливается во время initdb, для каждой базы данных, часто UTF-8) и тем, что клиент отправляет и ожидает получить. Значение по умолчанию — «the server’s encoding», то есть без преобразования. Контекст параметра — user, с переменной окружения PGCLIENTENCODING, которую libpq учитывает автоматически, по аналогии с application_name.
В мире UTF-8 этот параметр редко проявляется. Сервер — UTF-8, клиент — UTF-8, преобразования не происходит, жизнь хороша. Но «редко проявляется» — это не то же самое, что «не существует», и случаи, когда он проявляется, стоят понимания.