Устанавливает количество памяти, которое использует сервер базы данных для разделяемых буферов памяти. По умолчанию обычно устанавливается 128 мегабайт (128MB), но может быть меньше, если настройки ядра не поддерживают такое значение (как определяется во время выполнения initdb). Это значение должно быть не менее 128 килобайт. Однако, для хорошей производительности обычно требуются значительно более высокие значения. Если это значение указано без единиц измерения, оно считается в блоках, то есть BLCKSZ байт, обычно 8 кБ. (Нестандартные значения BLCKSZ изменяют минимальное значение). Этот параметр может быть установлен только при запуске сервера.

Если у вас есть выделенный сервер баз данных с 1 ГБ или более оперативной памяти, разумным начальным значением для shared_buffers будет 25% от объема памяти в вашей системе. Есть некоторые рабочие нагрузки, где даже большие значения для shared_buffers эффективны, но поскольку Tantor SE также полагается на кеш операционной системы, маловероятно, что выделение более 40% оперативной памяти для shared_buffers будет работать лучше, чем меньшее количество. Большие значения для shared_buffers обычно требуют соответствующего увеличения max_wal_size, чтобы распределить процесс записи больших объемов новых или измененных данных на более длительный период времени.

На системах с объемом оперативной памяти менее 1 ГБ, рекомендуется использовать меньший процент от объема памяти, чтобы оставить достаточно места для операционной системы.

Определяет, запрашиваются ли огромные страницы для основной общей памяти. Допустимые значения: try (по умолчанию), on и off. Если huge_pages установлено в try, сервер будет пытаться запросить огромные страницы, но вернется к значению по умолчанию, если это не удастся. При значении on неудачная попытка запроса огромных страниц приведет к невозможности запуска сервера. При значении off огромные страницы не будут запрашиваться.

В настоящее время эта настройка поддерживается только в Linux и Windows. На других системах она игнорируется, если установлена в значение try. В Linux она поддерживается только при установке shared_memory_type в значение mmap (по умолчанию).

Использование огромных страниц приводит к уменьшению размера таблиц страниц и сокращению времени ЦП, затрачиваемого на управление памятью, что повышает производительность. Дополнительные сведения о использовании огромных страниц в Linux см. в разделе Раздел 18.4.5.

Огромные страницы на Windows называются большими страницами. Чтобы использовать их, необходимо назначить право пользователя “Lock pages in memory” учетной записи пользователя Windows, от имени которого запускается Tantor SE. Вы можете использовать инструмент групповой политики Windows (gpedit.msc), чтобы назначить право пользователя “Lock pages in memory”. Чтобы запустить сервер базы данных в командной строке в качестве автономного процесса, а не в качестве службы Windows, командная строка должна быть запущена от имени администратора или отключено Управление доступом пользователя (UAC). Когда UAC включено, обычная командная строка отзывает право пользователя “Lock pages in memory” при запуске.

Обратите внимание, что этот параметр влияет только на основную область общей памяти. Операционные системы, такие как Linux, FreeBSD и Illumos, также могут автоматически использовать большие страницы (также известные как “супер” страницы или “большие” страницы) для нормального выделения памяти без явного запроса от Tantor SE. В Linux это называется “прозрачными огромными страницами”. (THP). Эта функция известна своей способностью вызывать снижение производительности для некоторых пользователей Tantor SE на некоторых версиях Linux, поэтому ее использование в настоящее время не рекомендуется (в отличие от явного использования huge_pages).

Управляет размером огромных страниц, когда они включены с помощью huge_pages. По умолчанию равно нулю (0). Когда установлено значение 0, будет использоваться размер огромной страницы по умолчанию в системе. Этот параметр может быть установлен только при запуске сервера.

Некоторые распространенные размеры страниц на современных 64-битных серверных архитектурах включают: 2MB и 1GB (Intel и AMD), 16MB и 16GB (IBM POWER), а также 64kB, 2MB, 32MB и 1GB (ARM). Дополнительную информацию о использовании и поддержке см. в Раздел 18.4.5.

На данный момент на Linux поддерживаются только нестандартные настройки.

Устанавливает максимальный объем памяти, используемой для временных буферов в каждой сессии базы данных. Эти буферы являются локальными для сессии и используются только для доступа к временным таблицам. Если это значение указано без единиц измерения, оно принимается в блоках, то есть в BLCKSZ байтах, обычно 8 кБ. По умолчанию установлено восемь мегабайт (8MB). (Если BLCKSZ не равно 8 кБ, значение по умолчанию масштабируется пропорционально ему). Это значение можно изменить в рамках отдельных сессий, но только до первого использования временных таблиц в рамках сессии; последующие попытки изменить значение не будут иметь никакого эффекта на эту сессию.

сессия выделяет временные буферы по мере необходимости, до предела, заданного переменной temp_buffers. Стоимость установки большого значения в сессиях, которым на самом деле не требуется много временных буферов, составляет всего лишь дескриптор буфера, или около 64 байтов, на каждое увеличение переменной temp_buffers. Однако, если буфер действительно используется, для него будет потребляться дополнительно 8192 байта (или в общем случае, BLCKSZ байтов).

Устанавливает максимальное количество транзакций, которые могут находиться в состоянии “подготовленных” одновременно (см. PREPARE TRANSACTION). Установка этого параметра в ноль (что является значением по умолчанию) отключает функцию подготовленных транзакций. Этот параметр может быть установлен только при запуске сервера.

Если вы не планируете использовать подготовленные транзакции, этот параметр должен быть установлен в ноль, чтобы предотвратить случайное создание подготовленных транзакций. Если вы используете подготовленные транзакции, вам, вероятно, захочется, чтобы max_prepared_transactions был не меньше, чем max_connections, чтобы каждая сессия могла иметь ожидающую подготовленную транзакцию.

При работе с резервным сервером необходимо установить этот параметр на такое же или более высокое значение, чем на основном сервере. В противном случае запросы на резервном сервере не будут разрешены.

Устанавливает базовое максимальное количество памяти, которое будет использоваться операцией запроса (например, сортировка или хеш-таблица) перед записью во временные файлы на диск. Если это значение указано без единиц измерения, оно принимается за килобайты. Значение по умолчанию — четыре мегабайта (4MB). Обратите внимание, что сложный запрос может выполнять несколько операций сортировки и хеширования одновременно, при этом каждой операции обычно разрешается использовать столько памяти, сколько указано в этом значении, прежде чем она начнет записывать данные во временные файлы. Также несколько выполняющихся сессий могут выполнять такие операции одновременно. Поэтому общее количество используемой памяти может быть в несколько раз больше значения work_mem; необходимо учитывать этот факт при выборе значения. Операции сортировки используются для ORDER BY, DISTINCT и слияния соединений. Хеш-таблицы используются в хеш-соединениях, хеш-агрегации, узлах мемоизации и хеш-обработке подзапросов с IN.

Операции на основе хеширования обычно более чувствительны к доступности памяти, чем эквивалентные операции на основе сортировки. Лимит памяти для хеш-таблицы вычисляется путем умножения work_mem на hash_mem_multiplier. Это позволяет операциям на основе хеширования использовать объем памяти, превышающий обычное базовое значение work_mem.

Используется для вычисления максимального объема памяти, который может использоваться для операций на основе хешей. Окончательное ограничение определяется путем умножения переменной work_mem на hash_mem_multiplier. Значение по умолчанию равно 2.0, что позволяет операциям на основе хешей использовать в два раза больше памяти, чем обычно, на основе базового значения переменной work_mem.

Рассмотрите возможность увеличения параметра hash_mem_multiplier в средах, где переполнение операций запросов является регулярным явлением, особенно когда простое увеличение параметра work_mem приводит к нехватке памяти (недостаток памяти обычно проявляется в виде периодических ошибок "out of memory"). Значение по умолчанию 2.0 часто является эффективным для смешанных рабочих нагрузок. Более высокие значения в диапазоне от 2.0 до 8.0 или более могут быть эффективными в средах, где параметр work_mem уже был увеличен до 40 МБ или более.

Определяет максимальный объем памяти, используемый операциями обслуживания, такими как VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. Если это значение указано без единиц измерения, оно считается в килобайтах. По умолчанию установлено значение 64 мегабайта (64MB). Поскольку только одна из этих операций может выполняться одновременно сессией базы данных, и обычно установлено небольшое количество таких операций, безопасно установить это значение значительно больше, чем work_mem. Более высокие значения могут улучшить производительность при выполнении операций очистки и восстановления базы данных.

Обратите внимание, что при запуске автоочистки может быть выделено памяти до autovacuum_max_workers раз, поэтому будьте осторожны с установкой слишком высокого значения по умолчанию. Может быть полезно контролировать это, отдельно устанавливая autovacuum_work_mem.

Обратите внимание, что для коллекции идентификаторов удаленных кортежей, VACUUM может использовать только до максимального объема памяти в 1GB.

Указывает максимальный объем памяти, который будет использоваться каждым рабочим процессом автоочистки. Если это значение указано без единиц измерения, оно считается в килобайтах. По умолчанию оно равно -1, что означает, что вместо него будет использоваться значение maintenance_work_mem. Это значение не влияет на поведение команды VACUUM при выполнении в других контекстах. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

Для сбора идентификаторов мертвых кортежей автоочистка может использовать только до максимального значения 1GB памяти, поэтому установка значения autovacuum_work_mem выше этого значения не влияет на количество мертвых кортежей, которые может собрать автоочистка при сканировании таблицы.

Задает размер Стратегии Доступа к Буферу, используемой командами VACUUM и ANALYZE. Установка значения 0 позволит операции использовать любое количество shared_buffers. В противном случае допустимые размеры варьируются от 128 кБ до 16 ГБ. Если указанный размер превышает 1/8 размера shared_buffers, размер будет молча ограничен этим значением. Значение по умолчанию — 256 кБ. Если это значение указано без единиц измерения, оно принимается за килобайты. Этот параметр можно установить в любое время. Он может быть переопределен для VACUUM и ANALYZE при передаче опции BUFFER_USAGE_LIMIT. Более высокие значения могут позволить командам VACUUM и ANALYZE выполняться быстрее, но слишком большое значение может привести к вытеснению слишком большого количества других полезных страниц из общих буферов.

Ограничивает максимальный объем памяти, используемой логическим декодированием, до того, как некоторые декодированные изменения будут записаны на локальный диск. Это ограничивает объем памяти, используемый соединениями логической потоковой репликации. По умолчанию установлено значение 64 мегабайта (64MB). Поскольку каждое соединение репликации использует только один буфер этого размера, и обычно установка имеет немного таких соединений одновременно (ограничено параметром max_wal_senders), безопасно установить это значение значительно выше значения work_mem, что уменьшит объем декодированных изменений, записываемых на диск.

Указывает объем памяти, используемой для кэширования содержимого pg_commit_ts (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается как блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 0, что запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.

Указывает количество общей памяти, используемой для кэширования содержимого pg_multixact/members (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 32. Этот параметр можно установить только при запуске сервера.

Указывает количество общей памяти, используемой для кэширования содержимого pg_multixact/offsets (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 16. Этот параметр можно установить только при запуске сервера.

Указывает объем общей памяти, используемой для кэширования содержимого pg_notify (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 16. Этот параметр можно установить только при запуске сервера.

Указывает количество общей памяти, используемой для кэширования содержимого pg_serial (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 32. Этот параметр можно установить только при запуске сервера.

Указывает количество общей памяти, используемой для кэширования содержимого pg_subtrans (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8кБ. Значение по умолчанию — 0, что запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.

Указывает количество общей памяти, используемой для кэширования содержимого pg_xact (см. Таблица 71.1). Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 0, что запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.

Указывает максимально безопасную глубину стека выполнения сервера. Идеальное значение для этого параметра - фактический лимит размера стека, установленный ядром (как установлено с помощью ulimit -s или аналогичной локальной команды), за вычетом запасного маржина в один мегабайт или около того. Запасной маржин необходим, потому что глубина стека не проверяется в каждой процедуре в сервере, а только в ключевых потенциально рекурсивных процедурах. Если это значение указано без единиц измерения, оно считается в килобайтах. Значение по умолчанию - два мегабайта (2MB), что является консервативно малым и маловероятно вызовет сбои. Однако, это может быть слишком мало для выполнения сложных функций. Изменить это значение могут только суперпользователи и пользователи с соответствующими привилегиями SET.

Установка переменной max_stack_depth выше фактического ограничения ядра означает, что бесконечно рекурсивная функция может вызвать сбой в отдельном процессе сервера. На платформах, где Tantor SE может определить ограничение ядра, сервер не позволит установить эту переменную на небезопасное значение. Однако не все платформы предоставляют эту информацию, поэтому рекомендуется быть осторожным при выборе значения.

Определяет реализацию общей памяти, которую сервер должен использовать для основной общей области памяти, содержащей общие буферы и другие общие данные Tantor SE. Возможные значения: mmap (для анонимной общей памяти, выделенной с помощью mmap), sysv (для общей памяти System V, выделенной через shmget) и windows (для общей памяти Windows). Не все значения поддерживаются на всех платформах; первое поддерживаемое значение является значением по умолчанию для этой платформы. Использование опции sysv, которая не является значением по умолчанию на любой платформе, обычно не рекомендуется, поскольку оно обычно требует изменения настроек ядра для разрешения больших выделений (см. Раздел 18.4.1).

Указывает реализацию динамической общей памяти, которую должен использовать сервер. Возможные значения: posix (для POSIX-совместимой общей памяти, выделенной с помощью shm_open), sysv (для общей памяти System V, выделенной с помощью shmget), windows (для общей памяти Windows) и mmap (для имитации общей памяти с использованием файлов с отображением в память, хранящихся в каталоге данных). Не все значения поддерживаются на всех платформах; обычно первое поддерживаемое значение является значением по умолчанию для данной платформы. Использование опции mmap, которая не является значением по умолчанию на любой платформе, обычно не рекомендуется, поскольку операционная система может многократно записывать измененные страницы на диск, увеличивая нагрузку на систему ввода-вывода; однако она может быть полезной для отладки, когда каталог pg_dynshmem хранится на оперативном диске, или когда другие средства общей памяти недоступны.

Определяет количество памяти, которое должно быть выделено при запуске сервера для использования параллельными запросами. Когда этот регион памяти недостаточен или исчерпан параллельными запросами, новые параллельные запросы пытаются временно выделить дополнительную общую память из операционной системы с использованием метода, настроенного с помощью параметра dynamic_shared_memory_type, что может быть медленнее из-за дополнительные издержки на управление памятью. Память, выделенная при запуске с помощью параметра min_dynamic_shared_memory, зависит от параметра huge_pages в операционных системах, где он поддерживается, и может более вероятно получить преимущества от использования больших страниц в операционных системах, где это управляется автоматически. Значение по умолчанию - 0 (отсутствует). Этот параметр может быть установлен только при запуске сервера.

Позволяет выделять память для объектов до 2 ГБ, вместо старого лимита в 1 ГБ. Это не влияет на максимальный размер поля.

Значение по умолчанию — off. Этот параметр можно установить в рамках пользовательской сессии с привилегиями суперпользователя с помощью команды SET, а также для всех подключений в конфигурации postgresql.conf с enable_large_allocations = on. Этот параметр следует включать только при необходимости обработки определенных полей таблицы.

Использование: Устраняет проблемы переполнения буфера при сериализации/десериализации типов данных bytea, text, с размерами от 0.5 до 1 ГБ, во время клиентских запросов, создания дампов базы данных с pg_dump, pg_dumpall, и загрузки дампов базы данных с pg_restore.

Ограничивает максимальный объем дискового пространства, которое процесс может использовать для временных файлов, таких как временные файлы сортировки и хеширования, или файл хранения для удерживаемого курсора. Транзакция, пытающаяся превысить это ограничение, будет отменена. Если это значение указано без единиц измерения, оно считается в килобайтах. Значение -1 (по умолчанию) означает отсутствие ограничения. Изменить это значение могут только суперпользователи и пользователи с соответствующими привилегиями SET.

Этот параметр ограничивает общее пространство, используемое в любой момент времени всеми временными файлами, используемыми процессом Tantor SE. Следует отметить, что дисковое пространство, используемое для явных временных таблиц, в отличие от временных файлов, используемых внутри запросов, не учитывается при подсчете этого ограничения.

Устанавливает максимальное количество одновременно открытых файлов, разрешенных для каждого серверного подпроцесса. По умолчанию разрешено открывать тысячу файлов. Если ядро применяет безопасное ограничение на количество файлов для каждого процесса, вам не нужно беспокоиться о этой настройке. Но на некоторых платформах (в основном, на большинстве систем BSD) ядро позволит отдельным процессам открывать гораздо больше файлов, чем система фактически может поддерживать, если множество процессов попытается открыть такое количество файлов. Если вы столкнулись с ошибками “Слишком много открытых файлов”, попробуйте уменьшить эту настройку. Этот параметр может быть установлен только при запуске сервера.

Количество времени, в течение которого процесс будет спать, когда достигнут предел стоимости. Если это значение указано без единиц измерения, оно считается в миллисекундах. Значение по умолчанию - ноль, что отключает функцию задержки очистки при превышении предела стоимости. Положительные значения включают очистку при превышении предела стоимости.

При использовании очистки на основе стоимости, подходящие значения для параметра vacuum_cost_delay обычно достаточно малы, возможно, меньше 1 миллисекунды. В то время как параметр vacuum_cost_delay может быть установлен с дробными значениями в миллисекундах, такие задержки могут измеряться неточно на старых платформах. На таких платформах увеличение регулируемого потребления ресурсов VACUUM выше значения 1 мс потребует изменения других параметров стоимости очистки. Тем не менее, необходимо, чтобы значение параметра vacuum_cost_delay было как можно меньше, чтобы ваша платформа могла точно измерять его; большие задержки не рекомендуются.

Оценочная стоимость для очистки буфера, найденного в общем буферном кеше. Она представляет собой стоимость блокировки пула буферов, поиска в общей хеш-таблице и сканирования содержимого страницы. Значение по умолчанию равно единице.

Оценочная стоимость для очистки буфера, который должен быть прочитан с диска. Это представляет собой усилия по блокировке буферного пула, поиску в общей хеш-таблице, чтению нужного блока с диска и сканированию его содержимого. Значение по умолчанию - 2.

Оценочная стоимость, взимаемая при выполнении операции VACUUM для изменения блока, который ранее был чистым. Она представляет собой дополнительные операции ввода-вывода, необходимые для сброса грязного блока на диск снова. Значение по умолчанию - 20.

Накопленная стоимость, которая заставит процесс очистки заснуть. Значение по умолчанию - 200.

Определяет задержку между раундами активности фонового записывающего процесса. В каждом раунде писатель выполняет запись для некоторого количества грязных буферов (управляемого следующими параметрами). Затем он спит в течение времени, указанного в bgwriter_delay, и повторяет процесс. Однако, когда в буферном пуле нет грязных буферов, он переходит в длительный сон, независимо от значения bgwriter_delay. Если это значение указано без единиц измерения, оно считается миллисекундами. Значение по умолчанию - 200 миллисекунд (200ms). Обратите внимание, что на многих системах эффективное разрешение задержек сна составляет 10 миллисекунд; установка значения bgwriter_delay, которое не является кратным 10, может привести к тем же результатам, что и установка следующего более высокого кратного 10. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

В каждом раунде фоновым писателем будет записано не более этого количества буферов. Установка этого значения в ноль отключает фоновую запись. (Обратите внимание, что контрольные точки, которые управляются отдельным, выделенным вспомогательным процессом, не затрагиваются). Значение по умолчанию - 100 буферов. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

Количество грязных буферов, записываемых за каждый раунд, определяется на основе количества новых буферов, которые были необходимы серверным процессам в последние раунды. Средняя недавняя потребность умножается на bgwriter_lru_multiplier для получения оценки количества буферов, которые будут необходимы в следующем раунде. Грязные буферы записываются до тех пор, пока не будет доступно такое же количество чистых, повторно используемых буферов. (Однако за один раунд будет записано не более bgwriter_lru_maxpages буферов). Таким образом, значение 1.0 представляет собой политику "вовремя" записи ровно того количества буферов, которое предполагается необходимым. Большие значения обеспечивают некоторую подушку от всплесков спроса, в то время как меньшие значения намеренно оставляют записи для выполнения серверными процессами. Значение по умолчанию - 2.0. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

Когда количество данных, записанных фоновым писателем, превышает эту величину, попытаться заставить ОС выполнять запись этих данных на нижележащее хранилище. Это позволит ограничить количество грязных данных в кеше страниц ядра, уменьшая вероятность задержек при выполнении fsync в конце контрольной точки или при записи ОС данных в больших пакетах в фоновом режиме. Часто это приводит к существенному снижению задержки транзакций, но также есть случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может ухудшиться. На некоторых платформах это значение может не иметь эффекта. Если это значение указано без единиц измерения, оно принимается в блоках, то есть BLCKSZ байт, обычно 8 КБ. Допустимый диапазон значений находится между 0, что отключает принудительную запись, и 2 МБ. По умолчанию на Linux установлено значение 512 КБ, в других случаях - 0. (Если BLCKSZ не равно 8 КБ, значения по умолчанию и максимальные значения масштабируются пропорционально этому значению). Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

Всякий раз, когда одним бэкендом было записано больше этого количества данных, попытайтесь заставить ОС выполнять эти записи в основное хранилище. Это позволит ограничить количество грязных данных в кеше страниц ядра, уменьшая вероятность задержек при выполнении fsync в конце контрольной точки или когда ОС записывает данные обратно в больших пакетах в фоновом режиме. Часто это приводит к существенному снижению задержки транзакции, но также есть случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может ухудшиться. Эта настройка может не иметь эффекта на некоторых платформах. Если это значение указано без единиц измерения, оно принимается в блоках, то есть в байтах BLCKSZ, обычно 8 кБ. Допустимый диапазон значений составляет от 0, что отключает принудительную запись, до 2MB. По умолчанию установлено значение 0, то есть принудительная запись отключена. (Если BLCKSZ не равно 8 кБ, максимальное значение масштабируется пропорционально ему).

Устанавливает количество одновременных операций ввода-вывода на диск, которые ожидает, что Tantor SE может выполнять одновременно. Повышение этого значения увеличит количество операций ввода-вывода, которые каждая отдельная сессия Tantor SE попытается инициировать параллельно. Допустимый диапазон значений: от 1 до 1000 или ноль для отключения асинхронных запросов ввода-вывода. В настоящее время это значение влияет только на сканирование кучи битовых карт.

Для магнитных дисков хорошей отправной точкой для этого параметра является количество отдельных дисков, составляющих полосу RAID 0 или зеркало RAID 1, используемые для базы данных. (Для RAID 5 диск с четностью не должен учитываться). Однако, если база данных часто занята множеством запросов, выполняемых в параллельных сессиях, могут быть достаточными более низкие значения, чтобы держать дисковый массив занятым. Значение, превышающее необходимое для занятости дисков, приведет только к дополнительной нагрузке на ЦП. SSD и другие носители на основе памяти часто могут обрабатывать множество параллельных запросов, поэтому наилучшее значение может быть в сотнях.

Асинхронный ввод-вывод зависит от эффективной функции posix_fadvise, которая отсутствует в некоторых операционных системах. Если функция отсутствует, то установка этого параметра в любое значение, кроме нуля, приведет к ошибке. В некоторых операционных системах (например, Solaris) функция присутствует, но на самом деле ничего не делает.

По умолчанию 1 на поддерживаемых системах, в противном случае 0. Значение этого параметра может быть переопределено для таблиц в определенном табличном пространстве путем установки параметра табличного пространства с тем же именем (см. ALTER TABLESPACE).

Аналогично effective_io_concurrency, но используется для обслуживающих работ, выполняемых от имени множества клиентских сессий.

По умолчанию значение равно 10 на поддерживаемых системах, в противном случае 0. Это значение может быть изменено для таблиц в определенном табличном пространстве путем установки параметра табличного пространства с тем же именем (см. ALTER TABLESPACE).

Устанавливает максимальное количество фоновых процессов, которые может поддерживать система. Этот параметр может быть установлен только при запуске сервера. По умолчанию установлено значение 8.

При работе с резервным сервером необходимо установить этот параметр на такое же или более высокое значение, чем на основном сервере. В противном случае запросы на резервном сервере не будут разрешены.

При изменении этого значения рассмотрите также настройки max_parallel_workers, max_parallel_maintenance_workers и max_parallel_workers_per_gather.

Устанавливает максимальное количество рабочих процессов, которые могут быть запущены одним узлом Gather или Gather Merge. Параллельные рабочие берутся из пула процессов, установленного с помощью max_worker_processes, ограниченного значением max_parallel_workers. Обратите внимание, что запрошенное количество рабочих процессов может фактически не быть доступным во время выполнения. Если это происходит, план будет выполняться с меньшим количеством рабочих процессов, чем ожидалось, что может быть неэффективно. Значение по умолчанию - 2. Установка этого значения в 0 отключает параллельное выполнение запроса.

Обратите внимание, что параллельные запросы могут потреблять значительно больше ресурсов, чем непараллельные запросы, поскольку каждый рабочий процесс является полностью отдельным процессом, который имеет примерно такое же влияние на систему, как дополнительная пользовательская сессия. Это следует учитывать при выборе значения для этой настройки, а также при настройке других параметров, которые контролируют использование ресурсов, таких как work_mem. Ограничения ресурсов, такие как work_mem, применяются индивидуально к каждому рабочему процессу, что означает, что общее использование может быть намного выше для всех процессов, чем для любого отдельного процесса. Например, параллельный запрос с использованием 4 рабочих процессов может использовать до 5 раз больше времени ЦП, памяти, пропускной способности ввода-вывода и так далее, чем запрос, который не использует рабочие процессы.

Для получения дополнительной информации о параллельном запросе см. Глава 15.

Устанавливает максимальное количество параллельных рабочих процессов, которые могут быть запущены одной утилитой. В настоящее время утилиты, поддерживающие использование параллельных рабочих, это только CREATE INDEX при построении индекса B-дерева и VACUUM без опции FULL. Параллельные рабочие процессы берутся из пула процессов, установленного параметром max_worker_processes, ограниченного параметром max_parallel_workers. Обратите внимание, что запрошенное количество рабочих процессов может фактически не быть доступным во время выполнения. Если это происходит, операция утилиты будет выполняться с меньшим количеством рабочих процессов, чем ожидалось. Значение по умолчанию - 2. Установка этого значения в 0 отключает использование параллельных рабочих процессов утилитами.

Обратите внимание, что команды параллельных утилит не должны потреблять существенно больше памяти, чем эквивалентные непараллельные операции. Эта стратегия отличается от параллельного запроса, где ограничения ресурсов обычно применяются к каждому рабочему процессу. Параллельные утилиты рассматривают ограничение ресурсов maintenance_work_mem как ограничение, применяемое к всей утилите, независимо от количества параллельных рабочих процессов. Однако, параллельные утилиты могут все равно потреблять существенно больше ресурсов ЦП и пропускной способности ввода-вывода.

Устанавливает максимальное количество рабочих процессов, которое система может поддерживать для параллельных операций. Значение по умолчанию - 8. При увеличении или уменьшении этого значения также рассмотрите возможность настройки параметров max_parallel_maintenance_workers и max_parallel_workers_per_gather. Также обратите внимание, что установка значения, превышающего max_worker_processes, не будет иметь эффекта, поскольку параллельные рабочие процессы берутся из пула рабочих процессов, установленного этим параметром.

Позволяет процессу-лидеру выполнять план запроса под узлами Gather и Gather Merge вместо ожидания рабочих процессов. По умолчанию значение on. Установка значения off снижает вероятность блокировки рабочих процессов из-за того, что лидер не читает кортежи достаточно быстро, но требует ожидания рабочих процессов перед тем, как можно будет произвести первые кортежи. Степень, в которой лидер может помочь или затруднить производительность, зависит от типа плана, количества рабочих процессов и продолжительности запроса.

Устанавливает минимальное время, в течение которого снимок запроса может быть использован без риска возникновения ошибки "слишком старый снимок" при использовании снимка. Данные, которые были удалены дольше этого порога, могут быть удалены очисткой. Это может помочь предотвратить раздутие в случае, когда снимки остаются в использовании в течение длительного времени. Чтобы предотвратить неправильные результаты из-за очистки данных, которые в противном случае были бы видны снимку, генерируется ошибка, когда снимок старше этого порога и снимок используется для чтения страницы, которая была изменена после построения снимка.

Если это значение указано без единиц измерения, оно считается в минутах. Значение -1 (по умолчанию) отключает эту функцию, эффективно устанавливая предел возраста снимка на бесконечность. Этот параметр может быть установлен только при запуске сервера.

Полезные значения для работы в производственной среде, вероятно, варьируются от нескольких часов до нескольких дней. Маленькие значения (например, 0 или 1min) разрешены только потому, что иногда они могут быть полезны для тестирования. Хотя значение вплоть до 60d разрешено, обратите внимание, что во многих рабочих нагрузках крайне непропорциональное раздутие или переполнение идентификаторов транзакций может произойти в гораздо более короткие сроки.

Когда эта функция включена, освобожденное пространство в конце отношения не может быть освобождено операционной системе, так как это может удалить информацию, необходимую для обнаружения состояния "слишком старый снимок". Все выделенное пространство для отношения остается связанным с этим отношением только для повторного использования внутри этого отношения, если оно явно не освобождается (например, с помощью VACUUM FULL).

Эта настройка не гарантирует возникновение ошибки в каких-либо определенных обстоятельствах. Фактически, если правильные результаты могут быть сгенерированы из (например) курсора, который материализовал набор результатов, то ошибка не будет сгенерирована, даже если базовые строки в целевой таблице были удалены при помощи VACUUM. Некоторые таблицы не могут быть безопасно очищены рано, и поэтому не будут затронуты этой настройкой, такие как системные каталоги. Для таких таблиц эта настройка не уменьшит раздутие и не создаст возможность возникновения ошибки “snapshot too old” при сканировании.