max_sync_workers_per_subscription определяет, сколько таблиц одна подписка копирует одновременно. Это не параметр, задающий скорость первоначального копирования, хотя именно для её увеличения многие и повышают его значение. Каждый рабочий процесс синхронизации таблиц копирует ровно одну таблицу — от начала до конца. Таким образом, параметр обеспечивает параллельную обработку разных таблиц, но никак не ускоряет копирование одной отдельной таблицы. Самая большая таблица будет копироваться одинаково долго независимо от того, установлено здесь значение 2, 8 или 200. А первоначальная синхронизация подписки не завершится раньше, чем закончится копирование этой таблицы.
Christophe Pettus: All Your GUCs in a Row: max_standby_archive_delay and max_standby_streaming_delay
max_standby_streaming_delay — это не ограничение времени выполнения запроса, какими бы ни казались его название и значение по умолчанию. Этот параметр задаёт величину отставания реплики, на которую вы готовы пойти ради выполнения запросов на резервном сервере. Когда отведённый запас исчерпан, отменяют именно запросы. max_standby_archive_delay выполняет ту же функцию для WAL, поступающего через restore_command, а не от процесса отправки WAL. Я буду рассматривать их как один параметр с двумя именами и объясню, зачем нужны оба.
Параметр max_slot_wal_keep_size определяет, кто погибнет, если реплика перестанет получать WAL: реплика или основной сервер. Значение по умолчанию выбирает основной сервер.
В статье Проблемы производительности при соединении временных таблиц SQL против табличных переменных я объяснял, почему следует избегать табличных переменных в операторах соединения. Проблема может стать более сложной, когда табличнозначный параметр используется в соединении в хранимой процедуре. Это происходит потому, что добавляется еще одна проблема, которая называется прослушиванием параметра (Parameter Sniffing). Если вас интересует, как решить эти проблемы, продолжайте читать, чтобы узнать больше.
Многие разработчики передают таблицу данных из приложения в хранимую процедуру. Затем они используют ее в операторе соединения (join) для фильтрации результатов. Хранимые процедуры могут получать эти данные как входной параметр при использовании табличнозначного параметра (TVP). Чтобы передать несколько строк при помощи TVP, вы должны определить пользовательский табличный тип данных. Вы можете больше узнать об этом в следующей статье. Продолжить чтение "Проблемы соединений табличнозначного параметра в хранимых процедурах SQL Server"
max_replication_slots — это размер массива в общей памяти, и ничего больше. Этот параметр не определяет, кому разрешено создавать слоты, сколько WAL может удерживать слот и когда система должна очищать заброшенные слоты. Он задаёт количество элементов в массиве. Сам массив выделяется один раз при запуске сервера, поэтому единственная действительно важная особенность этого значения заключается в том, что изменить его без перезапуска невозможно.
Работая над статьёй об улучшениях мониторинга в PostgreSQL 19 и готовя новый доклад о наблюдаемости PostgreSQL для конференции PostgreSQL Conference Europe, которая состоялась в октябре, я заметила, что в этом выпуске системным представлениям посвятили отдельный раздел. Последний раз им уделяли столь же заметное внимание в PostgreSQL 13 и 14. Поэтому я решила, что системные представления заслуживают отдельной статьи, в которой можно подробно разобрать все изменения.
Подготовленная транзакция — это транзакция, отделённая от своего сеанса. После выполнения команды PREPARE TRANSACTION 'some-gid' сеанс, в котором она была начата, больше не содержит никакой активной транзакции. Однако выполненные изменения, установленные блокировки и идентификатор транзакции продолжают существовать самостоятельно: информация о них записана в WAL, состояние отслеживается в общей памяти, а после аварийного завершения работы сервера транзакция восстанавливается и ожидает, пока кто-нибудь не выполнит COMMIT PREPARED 'some-gid' или ROLLBACK PREPARED 'some-gid'.
Параметр max_prepared_transactions определяет, сколько таких транзакций, существующих отдельно от своих сеансов, сервер может одновременно удерживать. Значение по умолчанию — 0, верхняя граница — 262143. Контекст настройки — postmaster, поэтому для включения этой возможности потребуется перезапуск сервера. Для её отключения перезапуск тоже необходим.
У параметра max_pred_locks_per_transaction есть та же проблема с названием, что и у max_locks_per_transaction, а вдобавок и собственная особенность. Как и его тезка, он определяет размер таблицы, рассчитанный на каждый слот серверного процесса, а не ограничивает количество блокировок отдельной транзакции. Но, в отличие от своего тезки, большая часть записей в этой таблице в любой момент времени относится к транзакциям, которые уже завершились фиксацией.
При использовании уровня изоляции SERIALIZABLE PostgreSQL должен запоминать, какие данные прочитала каждая транзакция. Для этого выделен определённый объём общей памяти, и он ограничен.
Эти два параметра определяют, в какой момент сервер перестаёт отслеживать отдельные строки и начинает учитывать всю страницу целиком, а затем — когда перестаёт отслеживать отдельные страницы и начинает учитывать всю таблицу. Каждое такое снижение точности отслеживания оборачивается ошибками сериализации, которых при более точном учёте можно было бы избежать.
Название параметра обещает параллельное применение изменений, поэтому любой, кто наблюдает за отставанием подписчика от издателя, рано или поздно находит его и надеется, что он решит проблему. Но возможности параметра гораздо уже, чем можно предположить.
fillfactor в PostgreSQL управляет тем, насколько заполняются страницы таблицы или индекса. Чем ниже fillfactor, тем выше производительность таблиц, подвергаемых массовым обновлениям. В этой статье мы узнаем все, что необходимо знать о fillfactor в PostgreSQL, начиная с понятия и заканчивая тем, когда именно (и как) вам следует его настраивать.
PostgreSQL обзавёлся множеством фоновых рабочих процессов, в том числе предназначенных для выполнения различных операций параллельно. Сейчас их стало так много, что разобраться во всём этом уже непросто. Давайте наведём порядок.
Ни один из этих параметров не означает того, что можно предположить по его названию.
max_parallel_workers_per_gather задаёт максимальное количество рабочих процессов, которое планировщик может запросить для одного узла плана выполнения. Однако обычно планировщик запрашивает меньше.
Параметр max_parallel_workers в документации описывается как ограничение, действующее для всего кластера. Но фактически оно обеспечивается сравнением общего количества работающих процессов с числом, которое каждый отдельный сеанс устанавливает самостоятельно.
Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_maintenance_workers
max_parallel_maintenance_workers — это верхнее ограничение, до которого в большинстве случаев просто не удаётся добраться: раньше срабатывает какое-нибудь другое ограничение. Параметр задаёт максимальное количество параллельных рабочих процессов, которые может запустить одна служебная команда. Значение по умолчанию — 2, контекст настройки — user, допустимый диапазон — от 0 до 1024. Значение 0 полностью отключает параллельное обслуживание. Увеличить значение параметра несложно. Гораздо труднее добиться того, чтобы команда действительно использовала выделенное ей количество процессов.
