Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_apply_workers_per_subscription
Название параметра обещает параллельное применение изменений, поэтому любой, кто наблюдает за отставанием подписчика от издателя, рано или поздно находит его и надеется, что он решит проблему. Но возможности параметра гораздо уже, чем можно предположить.
Продолжить чтение "Всё о GUC по порядку: max_parallel_apply_workers_per_subscription"Пересказ статьи Lee Asher. What is fillfactor in PostgreSQL – and when should you adjust it
Christophe Pettus: Workers of the World, Unite! – PostgreSQL Background Worker Configuration
PostgreSQL обзавёлся множеством фоновых рабочих процессов, в том числе предназначенных для выполнения различных операций параллельно. Сейчас их стало так много, что разобраться во всём этом уже непросто. Давайте наведём порядок.
Продолжить чтение "Рабочие процессы всех стран, объединяйтесь!"Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_workers and max_parallel_workers_per_gather
Ни один из этих параметров не означает того, что можно предположить по его названию.
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 полностью отключает параллельное обслуживание. Увеличить значение параметра несложно. Гораздо труднее добиться того, чтобы команда действительно использовала выделенное ей количество процессов.
§ Популярные темы недели на форуме
Топик Сообщений Просмотров
192 (SELECT) 8 2
209 (SELECT) 3 2
56 (Learn) 2 6
82 (Learn) 2 6
§ Авторы недели на форуме
Автор СообщенийПродолжить чтение "Новости за 2026-10-24 - 2026-10-30"
pegoopik 6
gennadi_s 6
8bobrik8 3
Murderface_ 2
Christophe Pettus: All Your GUCs in a Row: max_logical_replication_workers
max_logical_replication_workers определяет размер пула процессов. В документации перечислены три типа рабочих процессов, использующих этот пул (в PostgreSQL 19 их уже четыре), и на этом объяснение заканчивается. Но упущено самое важное: из всех перечисленных типов только один учитывается при выборе значения параметра, хотя при исчерпании пула ничего не завершается ошибкой. Просто подписка так и не сможет завершить свою работу.
Christophe Pettus: All Your GUCs in a Row: max_notify_queue_pages
Параметр max_notify_queue_pages никому не был нужен. Он появился потому, что ограничение, которое раньше обеспечивалось само собой, перестало работать, и пришлось придумать ему замену.
Christophe Pettus: All Your GUCs in a Row: max_locks_per_transaction
max_locks_per_transaction — это ни «на транзакцию», ни «максимум». Это доля на процесс в одной общей для всего кластера таблице блокировок, и любая отдельная транзакция может взять гораздо больше своей доли, пока никто другой не использует свою. Имя вводит людей в заблуждение с 7.2, а описание в документации как «среднего числа объектных блокировок, используемых каждой транзакцией» ближе к истине, хотя вряд ли это то, что вы нанесёте на ручку настройки.
Пересказ статьи sqlfingers. Tricks You May Not Be Using Yet
Автор Christophe Pettus: All Your GUCs in a Row: max_index_keys
max_index_keys считает вещи, которые не являются ключами, начиная с PostgreSQL 11. То, что он сообщает — 32, — это максимальное число столбцов в индексе, а с появлением INCLUDE столбец в индексе не обязательно является ключом: индекс с 31 ключом, несущий один INCLUDE-столбец, находится на пределе, как и индекс с одним ключом, несущий 31 такой столбец. Сообщение об ошибке говорит «столбцов» (cannot use more than 32 columns in an index), pg_controldata говорит Maximum columns in an index:, и только имя параметра всё ещё говорит о ключах.
Автор Christophe Pettus: The Sixth Execution
Вопрос обычно приходит как вопрос безопасности: «Стоит ли использовать параметры привязки, или можно собрать строку SQL самому?» Ответ на этот вопрос таков: используйте параметры привязки, сборка строки — это путь к SQL-инъекции, и все мы можем спокойно жить дальше.
Вопрос производительности, скрывающийся под ним, куда интереснее, и народная мудрость о нём в основном неверна. «Подготовленные операторы пропускают планирование» — обычная версия. Это верно лишь в узком наборе обстоятельств, и когда это верно, это не всегда хорошая новость. Эта статья о том, что PostgreSQL делает с запросом, значения которого впечатаны в текст, что он делает с запросом, значения которого приходят отдельно, и как кэш планов, стоящий между этими двумя путями, принимает свои решения. Есть конкретный момент — шестое выполнение подготовленного оператора, — где два пути расходятся, и удивительно много случаев «мой запрос стал медленным, а я ничего не менял» восходит именно к нему.
Продолжить чтение "Шестое выполнение подготовленного оператора"Автор Christophe Pettus: All Your GUCs in a Row: max_identifier_length
max_identifier_length сообщает число 63, и это число — самое неинтересное в нём. Каждая реляционная база данных ограничивает длину имени. Необычно в PostgreSQL то, что происходит, когда вы его превышаете: MySQL, SQL Server и Oracle отвергают оператор, а PostgreSQL обрезает имя до 63 байт, упоминает об этом в NOTICE и продолжает так, будто это то, что вы имели в виду. Почти каждая реальная проблема, связанная с этим параметром, восходит к этому одному решению.
Автор Christophe Pettus: All Your GUCs in a Row: max_files_per_process
max_files_per_process — это не лимит в том смысле, в каком его понимает большинство людей, когда превышение даёт ошибку. Это размер кэша. Каждый серверный процесс держит пул открытых файловых дескрипторов ядра, и когда пул полон, а серверному процессу нужен ещё один, он закрывает наименее недавно использованный и продолжает. Ничего не ломается. Запрос просто тратит пару дополнительных системных вызовов на файл, который был открыт тридцать секунд назад.
Автор Christophe Pettus: All Your GUCs in a Row: max_function_args
Никто не смотрит max_function_args намеренно. Вы встречаете его, когда PostgreSQL прерывает что-то несвязанное сообщением cannot pass more than 100 arguments to a function, и вы идёте искать ручку. Её нет.