Define a quantidade de memória que o servidor de banco de dados usa para buffers de memória compartilhada. O padrão é normalmente 128 megabytes (128MB), mas pode ser menor, se as configurações do núcleo não permitirem (conforme determinado durante initdb). Esta configuração deve ter pelo menos 128 kilobytes. Entretanto, são geralmente necessárias configurações muito maiores do que a mínima para um bom desempenho. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. (Valores não-padrão de BLCKSZ alteram o valor mínimo.) Este parâmetro só pode ser definido na ativação do servidor.

Se for um servidor de banco de dados dedicado, com 1 GB ou mais de RAM, o valor inicial razoável para shared_buffers é 25% da memória do sistema. Existem algumas cargas de trabalho em que configurações ainda maiores para shared_buffers são eficazes, mas como o PostgreSQL também depende do cache do sistema operacional, é improvável que uma alocação de mais de 40% de RAM para shared_buffers funcione melhor do que uma quantidade menor. Configurações maiores para shared_buffers geralmente requerem um aumento correspondente para max_wal_size, para distribuir o processo de escrita de grandes quantidades de dados novos ou alterados por um intervalo de tempo mais longo.

Em sistemas com menos de 1 GB de RAM, uma porcentagem menor de RAM é apropriada, de modo a deixar espaço adequado para o sistema operacional.

Controla se são requisitadas páginas de memória enormes (huge pages) para a área de memória compartilhada principal. Os valores válidos são: try (tentar) (o padrão), on, e off. Este parâmetro só pode ser definido na ativação do servidor. Com huge_pages definido como try, o servidor tentará requisitar páginas de memória enormes, mas retornará ao padrão se isto falhar. Com on, a falha ao requisitar páginas de memória enormes impedirá a ativação do servidor. Com off, não serão requisitadas páginas de memória enormes. O estado corrente das páginas de memória enormes é indicado pela variável do servidor huge_pages_status.

No momento, esta configuração é compatível apenas com os sistemas operacionais Linux e Windows. Esta configuração é ignorada nos outros sistemas operacionais quando definida como try. No Linux, há suporte apenas quando shared_memory_type está definido como mmap (o padrão).

O uso de páginas de memória enormes resulta em tabelas de páginas menores, e menos tempo de CPU gasto no gerenciamento de memória, melhorando o desempenho. Para obter mais detalhes sobre como usar páginas de memória enormes no Linux, veja Páginas de memória enormes (huge pages) no Linux.

As páginas de memória enormes são conhecidas como páginas grandes (large pages) no Windows. Para usá-las, é necessário atribuir o direito de Bloquear páginas na memória à conta do usuário do Windows que executa o PostgreSQL. Pode ser usada a ferramenta de políticas de grupo do Windows (gpedit.msc) para atribuir ao usuário o direito de “bloquear páginas na memória”. Para ativar o servidor de banco de dados no prompt de comando como um processo autônomo, e não como um serviço do Windows, o prompt de comando deve ser executado como administrador, ou o Controle de Acesso do Usuário (UAC) deve ser desativado. Quando o UAC está ativo, o prompt de comando normal revoga o direito do usuário de “bloquear páginas na memória” quando iniciado.

Note-se que esta configuração afeta apenas a área de memória compartilhada principal. Sistemas operacionais como Linux, FreeBSD e Illumos também podem usar páginas de memória enormes (também conhecidas como páginas “super” ou páginas “grande”), automaticamente, para alocação de memória normal, sem uma solicitação explícita do PostgreSQL. No Linux, isto é chamado de páginas de memória enormes transparentes (THP). Este recurso é conhecido por causar degradação de desempenho no PostgreSQL para alguns usuários em algumas versões do Linux, então no momento seu uso é desencorajado (ao contrário do uso explícito de huge_pages).

Controla o tamanho das páginas de memória enormes, quando ativadas com huge_pages. O padrão é 0. Quando definido como 0, será usado o tamanho de página de memória enorme padrão do sistema. Este parâmetro só pode ser definido na ativação do servidor.

Alguns tamanhos de página comumente disponíveis em arquiteturas modernas de servidor de 64 bits incluem: 2MB e 1GB (Intel e AMD), 16MB e 16GB (IBM POWER), e 64kB, 2MB, 32MB e 1GB (ARM). Para obter mais informações sobre uso e suporte, veja Páginas de memória enormes (huge pages) no Linux.

No momento, há suporte para as configurações não-padrão apenas no Linux.

Define a quantidade máxima de memória usada para buffers temporários em cada sessão do banco de dados. Estes são buffers locais de sessão usados apenas para acesso a tabelas temporárias. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O padrão é oito megabytes (8MB). (Se BLCKSZ não for 8kB, o valor padrão será dimensionado proporcionalmente a ele.) Esta configuração pode ser alterada em sessões separadamente, mas somente antes do primeiro uso de tabelas temporárias na sessão; as tentativas posteriores de alterar o valor não terão efeito nesta sessão.

A sessão irá alocar buffers temporários conforme necessário, até o limite estabelecido por temp_buffers. O custo de definir um valor grande em sessões que não precisam realmente de muitos buffers temporários é de apenas um descritor de buffer, ou cerca de 64 bytes, por incremento em temp_buffers. Entretanto, se o buffer for realmente usado, serão consumidos 8192 bytes adicionais por ele (ou, em geral, BLCKSZ bytes).

Define o número máximo de transações que podem estar no estado de “preparadas” simultaneamente (veja PREPARE TRANSACTION). Definir este parâmetro como zero (o padrão), desativa o recurso de transação preparada. Este parâmetro só pode ser definido na ativação do servidor.

Se não se planeja usar transações preparadas, este parâmetro deve ser definido como zero, para evitar a criação acidental de transações preparadas. Se estiverem sendo usadas transações preparadas, será provavelmente desejado que max_prepared_transactions seja pelo menos tão grande quanto max_connections, para que cada sessão possa ter uma transação preparada pendente.

Ao executar um servidor em-espera, deve-se definir este parâmetro com o mesmo valor, ou um valor superior, ao do servidor primário. Caso contrário, não serão permitidas consultas no servidor em-espera.

Define a quantidade máxima de memória base a ser usada por uma operação de consulta (como uma classificação ou tabela de hash), antes de escrever em arquivos de disco temporários. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O padrão é quatro megabytes (4MB). Note-se que uma consulta complexa pode realizar várias operações de ordenação e hash simultaneamente; geralmente, permite-se que cada operação utilize a quantidade de memória especificada por este valor antes de começar a escrever dados em arquivos temporários. Além disso, várias sessões em execução podem estar executando estas operações ao mesmo tempo. Portanto, a memória total usada pode ser muitas vezes o valor de work_mem; é preciso ter isto em mente na hora de escolher o valor. As operações de classificação são usadas para ORDER BY, DISTINCT, e junções por mesclagem. As tabelas de hash são usadas em junções por hash, agregações baseadas em hash, nós de memorização (memoize) e processamento baseado em hash de subconsultas IN.

Geralmente as operações baseadas em hash são mais sensíveis à disponibilidade de memória do que as operações baseadas em classificação equivalentes. O limite de memória para tabelas hash é calculado multiplicando work_mem por hash_mem_multiplier. Isto possibilita que operações baseadas em hash usem uma quantidade de memória que excede a quantidade base usual de work_mem.

Usado para calcular a quantidade máxima de memória que as operações baseadas em hash podem usar. O limite final é determinado pela multiplicação de work_mem por hash_mem_multiplier. O padrão é 2,0, o que faz com que as operações baseadas em hash utilizem o dobro da quantidade base usual de work_mem.

Deve-se considerar aumentar hash_mem_multiplier em ambientes onde uma grande quantidade de operações de consulta é uma ocorrência regular, especialmente quando simplesmente aumentar work_mem resulta em pressionar a memória (a pressão de memória assume normalmente a forma de erros intermitentes de falta de memória). A configuração padrão de 2.0 costuma ser eficaz com cargas de trabalho mistas. Configurações mais altas, na faixa de 2.0 a 8.0, ou mais, podem ser efetivas em ambientes onde work_mem já foi aumentado para 40 MB ou mais.

Especifica a quantidade máxima de memória a ser usada por operações de manutenção, como VACUUM, CREATE INDEX, e ALTER TABLE ADD FOREIGN KEY. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O padrão é 64 megabytes (64MB). Como apenas uma dessas operações pode ser executada por vez em uma sessão de banco de dados, e uma instalação normalmente não tem muitas delas sendo executadas simultaneamente, é seguro definir este valor muito maior que work_mem. Configurações maiores podem melhorar o desempenho para limpeza e restauração de cópias de segurança de banco de dados.

Note-se que quando se executa o autovacuum pode ser alocada até autovacuum_max_workers vezes esta memória, portanto deve-se tomar cuidado para não definir um valor padrão muito alto. Pode servir fazer o controle definindo separadamente autovacuum_work_mem.

Especifica a quantidade máxima de memória a ser usada por cada processo trabalhador do autovacuum. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O padrão é -1, indicando que deve ser usado o valor de maintenance_work_mem. Esta configuração não tem efeito sobre o comportamento do comando VACUUM quando executado em outros contextos. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica o tamanho da Estratégia de Acesso ao Buffer usado pelos comandos VACUUM e ANALYZE. Uma configuração de 0 permitirá que a operação utilize qualquer quantidade de shared_buffers. Caso contrário, os tamanhos válidos variam de 128 kB a 16 GB. Se o tamanho especificado exceder 1/8 do tamanho de shared_buffers, o tamanho é silenciosamente limitado a este valor. O padrão é 2MB. Se este valor for especificado sem unidade, é considerado como sendo kilobytes. Este parâmetro pode ser definido a qualquer momento, e pode ser sobreposto por VACUUM e ANALYZE ao se passar a opção BUFFER_USAGE_LIMIT. Configurações maiores podem permitir que VACUUM e ANALYZE sejam executados mais rapidamente, mas uma configuração excessivamente alta pode fazer com que muitas outras páginas úteis sejam removidas dos buffers compartilhados.

Especifica a quantidade máxima de memória a ser usada pela decodificação lógica, antes que algumas das alterações decodificadas sejam escritas no disco local. Este parâmetro limita a quantidade de memória usada por conexões de fluxo de replicação lógica. O padrão é 64 megabytes (64MB). Como cada conexão de replicação usa apenas um único buffer desse tamanho, e uma instalação normalmente não tem muitas dessas conexões simultâneas (conforme limitado por max_wal_senders), é seguro definir este valor muito maior que work_mem, reduzindo a quantidade de alterações decodificadas escritas no disco.

Especifica a quantidade de memória a ser usada para armazenar em cache o conteúdo de pg_commit_ts (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 0, o que requisita shared_buffers/512 até 1024 blocos, mas não menos que 16 blocos. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_multixact/members (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 32. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_multixact/offsets (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 16. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_notify (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 16. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_serial (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 32. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_subtrans (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 0, que requisita shared_buffers/512 até 1024 blocos, mas não menos que 16 blocos. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória compartilhada a ser usada para armazenar em cache o conteúdo de pg_xact (veja a Tabela 66.1). Se este valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, tipicamente 8 kB. O padrão é 0, que requisita shared_buffers/512 até 1024 blocos, mas não menos que 16 blocos. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a profundidade segura máxima da pilha de execução do servidor. A configuração ideal para este parâmetro é o limite de tamanho real da pilha imposto pelo núcleo (conforme definido por ulimit -s, ou o equivalente local), menos uma margem de segurança de um megabyte ou mais. A margem de segurança é necessária, porque a profundidade da pilha não é verificada em todas as rotinas do servidor, mas apenas nas principais rotinas potencialmente recursivas. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O padrão é dois megabytes (2MB), que é conservadoramente pequeno, e com pouca probabilidade de causar falhas. Entretanto, pode ser muito pequeno para permitir a execução de funções complexas. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Definir max_stack_depth maior que o limite real do núcleo significa que uma função recursiva descontrolada poderá travar um processo servidor individual. Em plataformas onde o PostgreSQL pode determinar o limite do núcleo, o servidor não permitirá que esta variável seja definida com um valor inseguro. Entretanto, nem todas as plataformas fornecem esta informação, portanto, recomenda-se cautela ao selecionar o valor.

Especifica a implementação de memória compartilhada que o servidor deve usar para a região principal de memória compartilhada que contém os buffers compartilhados do PostgreSQL, e outros dados compartilhados. Os valores possíveis são mmap (para memória compartilhada anônima alocada usando mmap), sysv (para memória compartilhada System V alocada via shmget), e windows (para memória compartilhada do Windows). Não há suporte para todos os valores em todas as plataformas; a primeira opção com suporte é o padrão para esta plataforma. O uso da opção sysv, que não é o padrão em nenhuma plataforma, é geralmente desencorajado, porque normalmente requer configurações do núcleo não-padrão para permitir grandes alocações (veja Memória compartilhada e semáforos). Este parâmetro só pode ser definido na ativação do servidor.

Especifica a implementação de memória compartilhada dinâmica que o servidor deve usar. Os valores possíveis são posix (para memória compartilhada POSIX alocada usando shm_open), sysv (para memória compartilhada System V alocada via shmget), windows (para memória compartilhada do Windows), e mmap (para simular memória compartilhada usando arquivos mapeados em memória armazenados no diretório de dados). Não há suporte para todos os valores em todas as plataformas; a primeira opção com suporte é geralmente o padrão para esta plataforma. O uso da opção mmap, que não é padrão em nenhuma plataforma, é geralmente desencorajado, porque o sistema operacional pode escrever páginas modificadas de volta no disco repetidamente, aumentando a carga de E/S do sistema; no entanto, pode servir para depuração, quando o diretório pg_dynshmem é armazenado em um disco em memória RAM, ou quando outros recursos de memória compartilhada não estão disponíveis. Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade de memória que deve ser alocada na ativação do servidor para uso por instruções paralelas. Quando esta região de memória é insuficiente, ou está esgotada por instruções simultâneas, as novas instruções paralelas tentam alocar memória compartilhada extra do sistema operacional usando temporariamente o método configurado com dynamic_shared_memory_type, que pode ser mais lento devido à sobrecarga de gerenciamento de memória. A memória alocada na ativação com min_dynamic_shared_memory é afetada pela configuração do parâmetro huge_pages em sistemas operacionais onde páginas enormes têm suporte, podendo ser provável que se beneficie mais de páginas enormes em sistemas operacionais onde estas são gerenciadas automaticamente. O padrão é 0 (nenhuma). Este parâmetro só pode ser definido na ativação do servidor.

Especifica a quantidade máxima de espaço em disco que um processo pode usar para arquivos temporários, como classificação e hash, ou o arquivo de armazenamento para um cursor mantido. Uma transação que tente exceder este limite será cancelada. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O valor -1 (o padrão) significa sem limite. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Esta configuração restringe o espaço total usado em qualquer instante por todos os arquivos temporários usados por um determinado processo do PostgreSQL. Deve-se observar que o espaço em disco usado para tabelas temporárias explícitas, em oposição aos arquivos temporários usados às escondidas na execução da consulta, não conta neste limite.

Especifica o método usado para copiar arquivos. Os valores possíveis são COPY (o padrão) e CLONE (se houver suporte do sistema operacional).

Este parâmetro afeta:

CLONE usa as chamadas de sistema copy_file_range() (Linux, FreeBSD), ou copyfile (macOS), dando ao núcleo a oportunidade de compartilhar blocos de disco ou delegar tarefas a camadas inferiores em alguns sistemas de arquivos.

Especifica o método usado para expandir arquivos de dados durante operações em massa, como COPY. A primeira opção disponível é usada como padrão, dependendo do sistema operacional:

O método write_zeros é sempre utilizado quando arquivos de dados são estendidos em 8 blocos ou menos.

Especifica a quantidade máxima de páginas alocadas para a fila de NOTIFY / LISTEN. O padrão é 1048576. Para páginas de 8 KB, permite consumir até 8 GB de espaço em disco. Este parâmetro só pode ser definido na ativação do servidor.

Define o número máximo de arquivos que cada subprocesso do servidor tem permissão para manter abertos simultaneamente; arquivos já abertos no postmaster não são contados para este limite. O padrão é mil arquivos.

Se o núcleo estiver aplicando um limite seguro por processo, não será necessário se preocupar com esta configuração. Entretanto, em algumas plataformas (notadamente na maioria dos sistemas BSD), o núcleo permite que processos individuais abram muito mais arquivos do que o sistema realmente aguentaria caso muitos processos tentassem abrir esta mesma quantidade de arquivos simultaneamente. Se forem encontradas falhas do tipo “muitos arquivos abertos”, deve-se tentar reduzir esta configuração. Este parâmetro só pode ser definido na ativação do servidor.

Especifica o atraso entre os retornos de atividade para o processo de escrita em segundo plano. A cada retorno, o processo de escrita em segundo plano causa escritas para um certo número de buffers sujos (controlável pelos parâmetros que se seguem). Em seguida, dorme pelo tempo de bgwriter_delay, e volta novamente. Entretanto, quando não há buffers sujos no pool de buffers, o processo entra em uma suspensão mais longa, independente de bgwriter_delay. Se este valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 200 milissegundos (200ms). Note-se que, em muitos sistemas, a resolução efetiva dos atrasos de inatividade é 10 milissegundos; configurar bgwriter_delay para um valor que não seja múltiplo de 10 pode ter os mesmos resultados que configurá-lo para o próximo múltiplo maior de 10. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

A cada volta, não mais do que esta quantidade de buffers será escrita pelo processo de escrita em segundo plano. Definir como zero desativa o processo de escrita em segundo plano. (Note-se que os pontos de verificação gerenciados por um processo auxiliar separado e dedicado, não são afetados.) O padrão é 100 buffers. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

O número de buffers sujos escritos a cada volta é baseado no número de novos buffers necessários para os processos servidores durante as voltas recentes. A necessidade recente média é multiplicada por bgwriter_lru_multiplier para chegar a uma estimativa do número de buffers que serão necessários durante a próxima volta. Os buffers sujos são escritos até chegar a este número de buffers limpos e reutilizáveis disponíveis. (Entretanto, não mais do que bgwriter_lru_maxpages buffers serão escritos por volta.) Assim, uma configuração de 1.0 representa uma política de escrever “na hora certa” (just in time) exatamente o número de buffers previstos para serem necessários. Valores maiores fornecem alguma proteção contra picos de demanda, enquanto valores menores deixam intencionalmente as escritas para serem feitas pelos processos servidores. O padrão é 2.0. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Sempre que mais do que esta quantidade de dados for escrita pelo processo de escrita em segundo plano, tenta forçar o sistema operacional a efetuar estas escritas no armazenamento subjacente. Fazer isto limita a quantidade de dados sujos no cache de páginas do núcleo, reduzindo a probabilidade de travamentos quando a função fsync for chamada no final do ponto de verificação, ou quando o sistema operacional escrever os dados em lotes maiores em segundo plano. Muitas vezes, isto resulta em latência de transação bastante reduzida, mas também há alguns casos, especialmente com cargas de trabalho maiores que shared_buffers, mas menores que o cache de páginas do sistema operacional, em que o desempenho pode diminuir. Esta configuração pode não ter efeito em algumas plataformas. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O intervalo válido está entre 0, que desativa a funcionalidade de escrita forçada, e 2MB. O padrão é 512kB no Linux, e 0 em outros sistemas operacionais. (Se BLCKSZ não for 8kB, os valores padrão e máximo serão dimensionados proporcionalmente ao mesmo.) Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Sempre que uma quantidade de dados maior do que esta for escrita por um único processo servidor, tenta forçar o sistema operacional a efetuar estas escritas no armazenamento subjacente. Fazer isto limita a quantidade de dados sujos no cache de páginas do núcleo, reduzindo a probabilidade de interrupções quando a função fsync for chamada no final do ponto de verificação, ou quando o sistema operacional escrever dados em lotes maiores em segundo plano. Muitas vezes, isto resulta em latência de transação bastante reduzida, mas também há alguns casos, especialmente com cargas de trabalho maiores que shared_buffers, mas menores que o cache de páginas do sistema operacional, em que o desempenho pode diminuir. Esta configuração pode não ter efeito em algumas plataformas. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O intervalo válido está entre 0, que desativa a funcionalidade de escrita forçada, e 2MB. O padrão é 0, ou seja, nenhuma escrita forçada. (Se BLCKSZ não for 8kB, o valor máximo será dimensionado proporcionalmente ao mesmo.)

Define o número de operações de E/S de armazenamento simultâneas que o PostgreSQL espera que possam ser executadas ao mesmo tempo. Aumentar este valor eleva o número de operações de E/S que qualquer sessão individual do PostgreSQL tenta iniciar em paralelo. O intervalo permitido é de 1 a 1000, ou 0 para desativar a emissão de solicitações de E/S assíncrona. O padrão é 16.

Valores mais altos terão maior impacto em armazenamento com latência mais elevada — onde, de outra forma, as consultas sofreriam interrupções de E/S perceptíveis — e em dispositivos com alto número de IOPS. Valores excessivamente altos podem aumentar a latência de E/S para todas as consultas no sistema.

Em sistemas com suporte a orientações de pré-busca (prefetch advice), effective_io_concurrency também controla a alcance da pré-busca.

Este valor pode ser sobreposto para tabelas em um espaço de tabelas específico, definindo o parâmetro do espaço de tabelas de mesmo nome (veja ALTER TABLESPACE).

Semelhante a effective_io_concurrency, mas usado para trabalho de manutenção feito em nome de muitas sessões cliente.

O padrão é 16. Este valor pode ser sobreposto para tabelas em um espaço de tabelas específico, definindo o parâmetro do espaço de tabelas de mesmo nome (veja ALTER TABLESPACE).

Controla o maior tamanho de E/S em operações que combinam E/S, e limita silenciosamente o parâmetro io_combine_limit configurável pelo usuário. Este parâmetro só pode ser definido na ativação do servidor. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O tamanho máximo possível depende do sistema operacional e do tamanho do bloco, mas é tipicamente 1 MB no Unix e 128 KB no Windows. O padrão é 128kB.

Controla o maior tamanho de E/S em operações que combinam E/S. Se definido com um valor superior ao do parâmetro io_max_combine_limit, será usado o valor mais baixo silenciosamente em seu lugar; portanto, pode ser necessário aumentar ambos para ampliar o tamanho de E/S. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O tamanho máximo possível depende do sistema operacional e do tamanho do bloco, mas é tipicamente 1 MB no Unix e 128 KB no Windows. O padrão é 128kB.

Controla o número máximo de operações de E/S que um processo pode executar simultaneamente.

A configuração padrão de -1 seleciona um número com base em shared_buffers e no número máximo de processos (max_connections, autovacuum_worker_slots, max_worker_processes e max_wal_senders), mas não mais que 64.

Este parâmetro só pode ser definido na ativação do servidor.

Seleciona o método para a execução de E/S assíncrona. Os valores possíveis são:

O padrão é worker.

Este parâmetro só pode ser definido na ativação do servidor.

Seleciona o número de processos trabalhadores de E/S a serem usados. O padrão é 3. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Só tem efeito se io_method estiver definido como worker.

Define o número máximo de processos em segundo plano que o sistema pode permitir. Este parâmetro só pode ser definido na ativação do servidor. O padrão é 8.

Ao executar um servidor em-espera, deve-se definir este parâmetro com o mesmo valor, ou um valor superior, ao do servidor primário. Caso contrário, não serão permitidas consultas no servidor em-espera.

Ao alterar este valor, deve-se considerar também ajustar max_parallel_workers, max_parallel_maintenance_workers e max_parallel_workers_per_gather.

Define o número máximo de processos trabalhadores que podem ser iniciados por um único nó Gather ou Gather Merge. Os processos trabalhadores paralelos são retirados do pool de processos estabelecido por max_worker_processes, e limitados por max_parallel_workers. Note-se que o número solicitado de processos trabalhadores pode não estar realmente disponível em tempo de execução. Se isto ocorrer, o plano será executado com menos processos trabalhadores do que o esperado, o que pode ser ineficiente. O padrão é 2. Definir este valor como 0 desativa a execução de consulta paralela.

Note-se que as consultas paralelas podem consumir muito mais recursos do que as consultas não paralelas, porque cada processo trabalhador é um processo inteiramente separado que tem aproximadamente o mesmo impacto no sistema que uma sessão de usuário adicional. Isto deve ser levado em consideração ao escolher um valor para esta configuração, bem como ao definir outras configurações que controlam a utilização de recursos, como work_mem. Limites de recursos como work_mem são aplicados individualmente a cada processo trabalhador, significando que a utilização total pode ser muito maior em todos os processos do que seria normalmente para qualquer processo único. Por exemplo, uma consulta paralela usando 4 processos trabalhadores pode usar até 5 vezes mais tempo de CPU, memória, largura de banda de E/S, e assim por diante, do que uma consulta que não usa nenhum processo trabalhador.

Para obter mais informações sobre consulta paralela, veja Consultas paralelizadas.

Define o número máximo de processos trabalhadores paralelos que um comando utilitário pode iniciar. No momento, os comandos utilitários com suporte ao uso de processos trabalhadores paralelos são CREATE INDEX ao construir índices de Árvore-B, GIN ou BRIN, e VACUUM sem a opção FULL. Os processos trabalhadores paralelos são retirados do pool de processos estabelecido por max_worker_processes, e limitados por max_parallel_workers. Note-se que o número solicitado de processos trabalhadores pode não estar realmente disponível em tempo de execução. Se isto ocorrer, a operação do utilitário será executada com menos processos trabalhadores do que o esperado. O padrão é 2. Definir este valor como 0 desativa o uso de processos trabalhadores paralelos em comandos utilitários.

Note-se que os comandos utilitários paralelos não devem consumir substancialmente mais memória do que as operações não paralelas equivalentes. Esta estratégia difere da consulta paralela, em que os limites de recursos geralmente se aplicam por processo trabalhador. Os comandos utilitários paralelos tratam o limite de recurso maintenance_work_mem como um limite a ser aplicado a todo o comando utilitário, independentemente do número de processos trabalhadores paralelos. Entretanto, os comandos utilitários paralelos ainda podem consumir substancialmente mais recursos de CPU e largura de banda de E/S.

Define o número máximo de processos trabalhadores que a instância pode permitir para operações paralelas. O padrão é 8. Ao aumentar ou diminuir este valor, deve-se considerar também ajustar max_parallel_maintenance_workers e max_parallel_workers_per_gather. Além disso, note que uma configuração para este valor maior que max_worker_processes não terá efeito, porque os processos trabalhadores paralelos são retirados do pool de processos trabalhadores estabelecidos por esta configuração.

Permite que o processo líder execute o plano de consulta em nós Gather e Gather Merge, em vez de esperar por processos trabalhadores. O padrão é on. Definir este valor como off reduz a probabilidade de que os processos trabalhadores sejam bloqueados porque o processo líder não está lendo as tuplas rápido o suficiente, mas exige que o processo líder aguarde a ativação dos processos trabalhadores antes que as primeiras tuplas possam ser produzidas. O grau em que o processo líder pode ajudar ou atrapalhar o desempenho depende do tipo de plano, número de processos trabalhadores, e duração da consulta.