§ Сложность задачи 20 (DML) увеличена до 2 баллов.
§ На этой неделе сертифицированы
NowOrNever (A26803008) [BK] - г.Санкт-Петербург, Россия
§ Популярные темы недели на форуме
Топик Сообщений ПросмотровПродолжить чтение "Новости за 2026-10-17 - 2026-10-23"
168 (Learn) 3 5
169 (Learn) 2 5
Автор Christophe Pettus: All Your GUCs in a Row: max_connections
max_connections — это бюджет памяти и автоматический выключатель, носящий костюм ёмкости. Он не решает, сколько запросов ваш сервер может выполнять одновременно; это решают количество ядер и хранилище, и они были решены, когда вы покупали оборудование. max_connections решает, сколько клиентских серверных процессов PostgreSQL создаст, прежде чем начнёт говорить «нет», и, что менее очевидно, сколько разделяемой памяти он откладывает в предположении, что каждый из них может появиться.
Автор Christophe Pettus: All Your GUCs in a Row: max_active_replication_origins
max_active_replication_origins — это десятилетний комментарий XXX, который наконец был оплачен. Он появился в PostgreSQL 18, и он существует потому, что то, чем он управляет, с 9.5 занимало число у другого параметра. На 14–17 число источников репликации, которые может отслеживать подписчик, задаётся max_replication_slots, параметром, чья настоящая работа — на издателе; с 16 документация всё равно перечисляет его в разделе для подписчика с примечанием, что он «также применяется на отправляющем сервере, но с другим значением». Отдельный параметр был впервые предложен в 2021 году и никуда не пошёл. Он ждал 18.
Автор Semab Tariq: How to Calculate Fillfactor for Your Tables
Небольшая настройка, которую большинство команд либо игнорируют, либо угадывают. Вот быстрая версия, а затем полный разбор.
Fillfactor задаёт, насколько полно Postgres упаковывает каждую страницу таблицы при записи, оставляя остальное как свободное пространство для будущих обновлений, которые попадут на место (HOT-обновления), что сокращает WAL и ввод-вывод.100 − (средний размер строки ÷ 8 192 × 100). Получите средний размер строки из pg_relation_size() и n_live_tup, запускайте после недавнего ANALYZE.Автор Christophe Pettus: All Your GUCs in a Row: maintenance_work_mem
maintenance_work_mem — это параметр памяти, который ведёт себя так, как люди ошибочно предполагают, что ведёт себя work_mem: одно выделение, для одной операции, в одном сеансе, и число, которое вы задаёте, — это число, которое используется. work_mem — это допуск на каждую сортировку, каждый хеш, каждого исполнителя, который один запрос может затребовать дюжину раз. maintenance_work_mem — это потолок. Документация говорит, что «безопасно устанавливать это значение значительно больше work_mem», и это одно из немногих мест, где вам дают разрешение быть щедрым, и в основном они правы. Эта статья о «в основном».
Автор Radim Marek: DELETEs are difficult
Ваша база данных работает как часы — пока простой DELETE не поставит её на колени. Что пошло не так? Хотя мы склонны сосредотачиваться на оптимизации операций SELECT и INSERT, мы часто упускаем из виду скрытую сложность DELETE. А ведь удаление ненужных данных столь же важно. Устаревшие или нерелевантные данные могут раздувать вашу базу данных, снижать производительность и делать обслуживание кошмаром. Хуже того, хранение некоторых типов данных без действительного обоснования может даже привести к проблемам соответствия.
Автор Christophe Pettus: All Your GUCs in a Row: maintenance_io_concurrency
maintenance_io_concurrency — это effective_io_concurrency для работы, которую документация описывает как выполняемую «от имени множества клиентских сеансов». Эта фраза — весь смысл дизайна: VACUUM выплачивает долг по вводу-выводу, который накопил каждый сеанс, поэтому он может разумно быть более агрессивным в упреждающем чтении, чем любой из них. Механически эти два параметра — одна и та же ручка, включая трёхэтапную историю того, что означает число, и я не буду повторять это здесь. Эта статья о том, какая работа управляется им, потому что список не таков, как подсказывает название.
Автор Christophe Pettus: All Your GUCs in a Row: logical_decoding_work_mem
logical_decoding_work_mem — это то, сколько чужой незафиксированной транзакции walsender будет держать в памяти, прежде чем начнёт записывать эту транзакцию на диск во второй раз.
Пересказ статьи sqlfingers. When SQL Server Isn’t the Bottleneck
Автор Christophe Pettus: All Your GUCs in a Row: log_parser_stats, log_planner_stats, log_executor_stats, and log_statement_stats
Это самые старые параметры журналирования, которые PostgreSQL всё ещё поставляет, и вывод выглядит соответственно. Каждый из них — булев параметр, по умолчанию выключен, контекст superuser, и каждый заставляет серверный процесс вызывать getrusage() до и после одной стадии выполнения оператора и записывать разницу в журнал на уровне LOG. log_parser_stats покрывает парсер, анализ разбора и переписчик (три блока на оператор, по одному на стадию); log_planner_stats покрывает планировщик; log_executor_stats покрывает исполнитель; а log_statement_stats покрывает весь оператор, поэтому он отказывается включаться вместе с любым из других трёх, и они отказываются включаться вместе с ним. Вывод для одного SELECT count(*) при включённом log_statement_stats:
Автор Christophe Pettus: All Your GUCs in a Row: log_lock_waits and log_lock_failures
log_lock_waits — самый дешёвый детектор конкуренции за блокировки, который поставляет PostgreSQL, и вплоть до версии 18 он по умолчанию выключен. Включите его. PostgreSQL 19 сделает это за вас.
§ Новая задача от Pegoopik выставлена на третий этап под номером 192 (сложность 4 балла).
§ В ответ на сообщение 8bobrik8 усилена проверка задачи 45 (обучающий этап).
§ Изменения среди лидеров рейтинга
Рейтинг Участник (решенные задачи)Продолжить чтение "Новости за 2026-10-10 - 2026-10-16"
1 pegoopik (192)
14 gennadi_s (208)
117 Paulus73 (140)
Автор Christophe Pettus: All Your GUCs in a Row: log_replication_commands
log_replication_commands — это log_statement = all для walsender'ов, с той единственной разницей, что его следует включить.
Автор Christophe Pettus: All Your GUCs in a Row: log_startup_progress_interval and log_recovery_conflict_waits
Эти два параметра отвечают на один и тот же вопрос об одном и том же процессе: что делает процесс запуска и почему он ещё не закончил? Процесс запуска — это серверный процесс, который воспроизводит WAL. На первичном сервере он существует только во время восстановления после сбоя, и пока он существует, ничто другое не может подключиться; клиент получает FATAL: the database system is not yet accepting connections. Когда он завершается, он выходит, и postmaster открывает двери. На standby он никогда не завершается; он воспроизводит в течение всей жизни сервера, и вопрос там не в том, как далеко он продвинулся, а в том, почему он остановился. Один параметр — для каждой из ситуаций, и оба отвечают в журнале сервера, потому что в обеих ситуациях журнал — единственное место, куда можно посмотреть.
Автор Christophe Pettus: All Your GUCs in a Row: client_connection_check_interval
По-настоящему полезный параметр, о котором почти никто не знает. Добавлен в PostgreSQL 14, по умолчанию выключен, исправляет конкретную патологию, которую каждый, кто запускал аналитические нагрузки, пережил хотя бы раз.
Продолжить чтение "Всё о GUC по порядку: client_connection_check_interval</h1>"