Revisão do postgresql.conf

Comparações e Observações sobre versões do portgresql.conf

Este documento é uma comparação das versões do arquivo postgresql.conf do PostgreSQL nas versões 8.2, 8.1, 8.0 e 7.4, que serão as versões suportadas pela
equipe do PostgreSQL a partir do lançamento da versão 8.2. A documentação a respeito da versão 8.2 foi realizada a partir da versão 8.2 beta3 e pode sofrer
atualizações até a versão definitiva da documentação. Erros de tradução, digitação, omissões e sugestões podem ser enviadas para Fábio Telles em
fabio.telles@gmail.com para que este documento possa ser melhorado.

Notas de Copyright
Este documento foi compilado por Fábio Telles e pode ser modificado e redistribuído nos termos das licenças abaixo, que são as fontes as informações
utilizadas para a realização do presente documento.
As observações deste documento são traduções do artigo Annotated POSTGRESQL.CONF Guide for PostgreSQL de Josh Berkus e Joe Conway disponível em
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html Licenciado pela Licença OPL
A coluna documentação é baseada na tradução da documentação do PostgreSQL em portug uês disponível em http://pgdocptbr.sourceforge.net/pg80/ realizada
pelo Projeto de Tradução para o Português do Brasil a partir da documentação oficial, Copyright © 1996-2006 The PostgreSQL Glo bal Development Group

Locais dos Arquivos
Configurado
Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão em
Documentação OBS
data_directory (string) X X X Diretório ConfigDir Inicialização Especifica o diretório a ser utilizado para Estas configurações permitem a fácil
armazenamento dos dados. administração de uma instalação do
PostgreSQL onde várias configurações e
config_file (string) X X X Arquivo ConfigDir/ Inicialização Especifica o arquivo principal de configuração do
arquivos de monitoramento são
postgresql.conf servidor.
separados do banco de dados em si,
hba_file (string) X X X Arquivo ConfigDir/ Inicialização Especifica o arquivo de configuração para usualmente para propósitos de arquivos
pg_hba.conf autenticação baseada no hospedeiro. de administração com especificações
particulares, ou para automatizar testes
com diferentes configurações.
Se você usar isto, será necessário apenas
especificar a localização do arquivo

Locais dos Arquivos

postgresql.conf em si quando iniciar o
postmaster (usando a opção -D ou
ConfigDir/ Especifica o arquivo de configuração para a
ident_file (string) X X X Arquivo
pg_ident.conf
Inicialização
autenticação ident.
PGDATA). Esta nova abordagem é
considerada melhor do que criar links
simbólicos, a única opção anterior.

Locais dos Arquivos
Isto é para programas de administração e
Interfaces GUI que esperam encontrar o
Especifica o nome de um arquivo de identificação PID do PostgreSQL num local específico,
external_pid_file de processo adicional, que o postmaster deve usualmente em /var. Tenha em mente que
(string)
X X X Arquivo Inicialização
criar para uso pelos programas de administração este é apenas uma cópia do PID e não
do servidor. aquele checado pelo pg_ctl na
inicialização do servidor, que será
checado no diretório de dados.

Conexões e Autenticação
Configurado
Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS
em
X X X -h
Definições da Conexão

listen_addresses localhost Inicialização Especifica o endereço, ou endereços, de TCP/IP Esta configuração substitui “tcp_ip” e
(string) x onde o servidor atende as conexões dos “virtual_host” do 7.4. A maioria dos
aplicativos cliente. O valor tem a forma de uma usuários irão querer configurar em '*'
-i lista de nomes de hospedeiros, ou de endereços para escutar todos os endereços ou
numéricos de IP, separados por vírgula. A deixar isto em 'localhost' para uma
entrada especial * corresponde a todas as máquina segura. Ao contrário das versões
interfaces de IP disponíveis. Se a lista estiver anterioras, o padrão agora suporta
vazia, o servidor não atende nenhuma interface conexões TCP/IP em 127.0.0.1 de forma
IP e, neste caso, somente podem ser utilizados que um servidor web local possa conectar
soquetes do domínio Unix para conectar ao logo após a instalação padrão.
servidor de banco de dados. O valor padrão é
Por motivo de segurança, altere isto após
localhost, que permite serem feitas apenas
configurar o seu arquivo pg_hba.conf.
conexões locais quot;retornantesquot; (loopback).
tcpip_socket X on / off off Inicialização Se for verdade, então o servidor aceita conexões Substituído pelo listen_addreses a partir
(boolean) TCP/IP. Senão, somente são aceitas conexões da versão 8.0.
oriundas do soquete do domínio Unix local. O
valor padrão é desabilitado.
virtual_host X Inicialização Especifica o nome de hospedeiro ou endereço Substituído pelo listen_addreses a partir
(string) de IP onde o servidor está escutando as da versão 8.0.
conexões das aplicações cliente. O padrão é
escutar em todos os endereços configurados
(incluindo localhost).
port (integer) X X X X 129 a 5432 Inicialização -p A porta TCP onde o servidor está atendendo; A principal razão para utilizar uma porta
32768 # 5432 por padrão. Deve ser observado que é alternativa é a necessidade de rodar mais
utilizada a mesma porta em todos os endereços de um servidor PostgreSQL numa
de IP onde o servidor atende. máquina, como durante um upgrade.
Uma alternativa a isto é a opção em
tempo de compilação –with-port que
configura uma porta alternativa em todas
as bibliotecas, retirando a necessidade de
lembrar da opção -p em todos os clientes
utilitários.
max_connection X X X X 2a 100 Inicialização - N Determina o número máximo de conexões Mantenha o mais baixo possível para a

Configurado
em
s (integer) 262143 # simultâneas ao servidor de banco de dados. O sua aplicação, uma vez que cada conexão
valor típico é 100, mas pode ser menor se a ativa requer recursos de sistema
configuração do núcleo do sistema operacional significativos. Aplicações Web servindo
não não tiver capacidade para suportar este centenas de usuários devem utilizar um
valor (conforme determinado durante o initdb). pool de conexões para reduzir o número
Somente pode ser definido na inicialização do de conexões requeridas no banco de
servidor. O aumento deste parâmetro pode fazer dados. Aumentando isto, irá requerer
com que o PostgreSQL requisite mais memória ajustes no limite de memória do seu SO.
compartilhada System V que o permitido pela
configuração padrão do sistema operacional.
Para obter informações sobre como ajustar
estes parâmetros deve ser consultada a Seção
16.5.1 , se for necessário.
superuser_reser X X X X 0a 2 Inicialização Determina o número de quot;encaixes de conexãoquot; Isto protege o acesso como super usuário
ved_connections max_con (connection slots), reservados para os em caso do banco de dados $$$. Não
(integer) nections superusuários do PostgreSQL se conectarem. configure isto em 0 a não ser que você
-1 Podem estar ativas até max_connections tiver muita certeza de que o banco de
conexões simultâneas. Sempre que o número de dados não pode ser quebrado. Eu sempre
conexões ativas simultâneas for igual ou maior a configuro em 1, uma vez que apenas eu
max_connections menos conecto ao banco de dados como super
superuser_reserved_connections, somente serão usuário no caso de ocorrer algum
aceitas novas conexões feitas por superusuários. problema. A configuração padrão é 2
O valor padrão é 2. O valor deve ser menor que para o caso de algum utilitário
o valor de max_connections. administrativo ficar continuamente
conectado como o autovacuum.
unix_socket_dire X X X X '' Inicialização Especifica o diretório do soquete do domínio
ctory (string) Unix onde o servidor está atendendo as
conexões dos aplicativos cliente. Normalmente o
valor padrão é /tmp, mas pode ser mudado em
tempo de construção.
unix_socket_gro X X X X '' Inicialização Define o grupo dono do soquete do domínio
up (string) Unix (O usuário dono do soquete é sempre o
usuário que inicializa o servidor). Combinado
com o parâmetro unix_socket_permissions pode

Configurado
em
ser utilizado como um mecanismo de controle
de acesso adicional para as conexões do
domínio Unix. Por padrão é uma cadeia de
caracteres vazia, que utiliza o grupo padrão do
usuário corrente.
unix_socket_per X X X X 0777 Inicialização Define as permissões de acesso do soquete do
missions domínio Unix. Os soquetes do domínio Unix
(integer) utilizam o conjunto usual de permissões do
sistema de arquivos do Unix. Para o valor deste
parâmetro, é esperada uma especificação de
modo numérica, na forma aceita pelas
chamadas de sistema chmod e umask (Para
utilizar o formato octal, como é de costume, o
número deve começar por 0 (zero)). As
permissões padrão são 0777, significando que
qualquer um pode se conectar. Alternativas
razoáveis são 0770 (somente o usuário e o
grupo, consulte também unix_socket_group), e
0700 (somente o usuário); deve ser observado
que, na verdade, para soquetes do domínio Unix
somente a permissão de escrita tem
importância, não fazendo sentido conceder ou
revogar permissões de leitura e de execução.
Este mecanismo de controle de acesso é
independente do descrito no Capítulo 19 .

bonjour_name X X '' Inicialização Especifica o nome de difusão (broadcast)
(string) Bonjour. O nome do computador é utilizado se o
parâmetro usar o valor de uma cadeia de
caracteres vazia (''). Este parâmetro é ignorado
se o servidor não for compilado com suporte ao
Bonjour.

tcp_keepalives_i X X 0 Inicialização Em sistemas com suporte a opção de soquete
dle (integer) TCP_KEEPIDLE, especifica o número de

Configurado
em
segundos entre o envio de keepalives em uma
conexão ociosa. O valor 0 utiliza o padrão do
sistema. Se TCP_KEEPIDLE não é suportado,
este parâmetro precisa ser 0. Este parâmetro é
ignorado para conexões feitas através de
soquete Unix.

Em sistemas que suporta ma opção de soquete
TCP_KEEPINTVL, especifica o quão longa é, em
segundos, a espera por uma resposta para o
tcp_keepalives_i keepalive antes de uma retransmissão. O valor 0
nterval (integer)
X X 0 Inicialização usa o padrão do sistema. Se o TCP_KEEPINTVL
não é suportado, este parâmetro precisa ser 0.
Este parâmetro é ignorado para conexões feitas
através de soquete Unix.

Em sistemas que suportam a opção de soquete
TCP_KEEPCNT, especifica quantos keepalives
podem ser perdidos antes da conexão ser
tcp_keepalives_c considerada morta. Um valor de 0 usa o padrão
ount (integer)
X X Inicialização do sistema. Se o TCP_KEEPCNT não é
suportado, este parâmetro precisa ser 0. Este
parâmetro é ignorado para conexões feitas
através de soquete Unix.

Especifica o nome de difusão (broadcast)
Rendezvous. Por padrão é utilizado o nome do
rendezvous_nam computador, especificado através de uma cadeia
e (string)
X X '' Inicialização de caracteres vazia (''). É ignorado quando o
servidor não é compilado com suporte a
Rendezvous.

Configurado
em
Segurança e autenticação

Tempo máximo, em segundos, para completar a
autenticação do cliente. Se a tentativa de Se você está rodando um servidor web
tornar-se cliente não completar o protocolo de ocupado, você irá querer diminuir o
autenticação nesta quantidade de tempo, o timeout da conexão. Certamente você vai
authentication_ti
1 a 600 servidor derruba a conexão. Isto impede que querer combinar com o timeout do seu
meout (integer) X X X X seg.
60 Reload
middleware, ou então você poderá ficar
clientes travados fiquem ocupando a conexão
indefinidamente. Somente pode ser definido na desnecessariamente indisponível ou vai
inicialização do servidor, ou no arquivo esperar muito durante os períodos
postgresql.conf. ocupados.

O SSL é uma alternativa criptografada ao
acesso plano a porta TCP/IP, e é um
requerimento para clientes preocupados
com a segurança da informação,
Habilita conexões SSL. Por favor leia a Seção particularmente em uma rede wireless. O
ssl (boolean) X X X X on / off off Inicialização 16.7 antes de utilizar este parâmetros. PostgreSQL envia consultas e dados em
texto plano, mesmo quando a senha está
encriptada. SSL pode ser complicado de
configurar e dar manutenção, e nem
todos softwares clientes podem suportar
o acesso SSL.
Quando é especificada uma senha em CREATE Deve estar habilitado, no arquivo de
USER ou ALTER USER , sem que seja escrito configuração e por conexão. Não há
password_encry ENCRYPTED ou UNENCRYPTED, este
ption (boolean)
X X X X on / off On Inicialização nenhuma razão para ter um banco de
parâmetro determina se a senha deve ser dados com senhas de usuários não
criptografada. encriptados.

Configura a localização do arquivo com a chave
krb_server_keyfil do servidor Kerberos. Veja Secção 19.2.3 para Apenas utilizado para usuários com
e (string)
X X X X '' Inicialização
autenticação Kerberos.
detalhes.

krb_srvname Configura o nome do serviço Kerberos. Veja a
(string) X X '' Inicialização Seção 20.2.3 para detalhes.

Configurado
em
krb_server_host X X '' Inicialização Configura o nome da parte hospedeira do
name (string) serviço principal. Este, combinado com
krb_srvname, é utilizado para gerar o serviço
completo principal que é krb_srvname/
krb_server_hostname@ REALM.
Se não for configurado, o padrão é o nome do
host. Veja Seção 20.2.3 para detalhes.

krb_caseins_user X X on / off off Inicialização Configura de os nomes dos usuários Kerberos
s (boolean) devem ser tratados como insensíveis a
maiúsculas e minúsculas (case-insensitive). O
padrão é off (case sensitive).

db_user_namesp X X off Inicialização Permite nomes de usuário por banco de dados. Esta funcionalidade suporta instalações
ace (boolean) O valor padrão é falso. Se o valor for verdade, (como em provedores de acesso) onde é
os usuários devem ser criados como necessário usuários por banco de dados.
nome_do_usuário@nome_bd. Quando o É uma forma deselegante na melhor das
nome_do_usuário é passado por um cliente se hipóteses e será removida quando uma
conectando, são anexados @ e o nome do banco solução melhor para este problema for
de dados ao nome do usuário, então o servidor criada. Assim, não use esta opção se você
procura por este nome de usuário específico do puder viver sem ela.
banco de dados. Deve ser observado que, no
ambiente SQL, para criar nomes de usuário
contendo @ é necessário colocar o nome de
usuário entre aspas. Quando o valor deste
parâmetro é verdade, ainda podem ser criados
usuários globais comuns. Deve apenas ser
anexado o caractere @ à especificação do nome
de usuário no cliente. O caractere @ será
retirado antes do nome de usuário ser
procurado pelo servidor.
Nota: Esta funcionalidade foi criada
como uma medida temporária até
que seja encontrada uma solução
definitiva, quando então será

Configurado
em
removida.

Consumo de recursos
Configurado
em
X X X X -B
Memóriai

shared_buffers 16 a 1000 Inicialização Define o número de buffers de memória Configurar o shared_buffers requer uma
(integer) 2621143 (4000 na x compartilhada, utilizados pelo servidor de banco discussão mais longa que este espaço
na de dados. O valor típico é 1000, mas pode ser dispõe. Por favor veja outro artigo sobre
versão menor se a configuração do núcleo do sistema este tópico.
8.2) operacional não não tiver capacidade para
Para regras práticas: em um servidor
suportar este valor (conforme determinado
PostgreSQL dedicado, este valor deve
durante o initdb). Cada buffer possui 8192
estar entre 1000 e 50000 (8MB e
bytes, a menos que seja escolhido um valor
400MB). Fatores que aumentam o
diferente para BLCKSZ ao construir o servidor.
montante recomendado são mais
O valor definido deve ser pelo menos igual a 16,
conexões, porções mais largas do banco
assim como pelo menos duas vezes o valor de
de dados ativas, consultas longas e
max_connections ; entretanto, normalmente é
complexas e tabelas largas. A RAM
necessário definir um valor bem maior que o
avaliável limita o máximo shared_buffers;
mínimo para obter um bom desempenho. São
você deve usar no máximo 1/3 da sua
recomendados valores de alguns poucos
RAM avaliável.
milhares para instalações de produção. Somente
pode ser definido na inicialização do servidor. O
aumento deste parâmetro pode fazer com que o
PostgreSQL requisite mais memória
compartilhada System V que o permitido pela
configuração padrão do sistema operacional.
Para obter informações sobre como ajustar
estes parâmetros deve ser consultada a Seção
16.5.1 , se for necessário.

sort_mem X 1024 Inicialização Equivalente a opção work_men.
(integer)
vacuum_mem X 8192 Inicialização Equivalente a opção maintenance_work_mem.
(integer)
temp_buffers X X 1000 Inicialização Ajusta o número máximo de buffers temporários
(integer) usados por cada seção do banco de dados. Estes
buffers são locais a sessão e usados apenas no
acesso a tabelas temporárias. A configuração
pode ser trocada em sessões individuais, mas

apenas até o primeiro uso de uma tabela
temporária na sessão; subseqüentes tentativas
de alterar o valor não terão efeito nesta sessão.
Uma sessão irá alocar buffers temporários
conforme a necessidade até o limite dado por
temp_buffers. O custo desta configuração em
um valor grande em sessões que atualmente não
necessitam de muito temporary_buffers é
apenas o descritor do buffer, ou cerca de 64
bytes, por incremento no temp_buffers.
Contudo, se um buffer é atualmente utilizado
um adicional de 8192 bytes (ou geralmente,
BLCKSZ bytes).

Ajusta o número máximo de transações que
podem estar “preparadas” simultaneamente
(veja PREPARE TRANSACTION ). Configurando
este parâmetro para zero desabilita a
funcionalidade de transações preparadas.
Se você não está usando transações preparadas,
este parâmetro poderá ser configurado para
max_prepared_tr zero. Se você utiliza-las, você provavelmente irá
ansactions querer que max_prepared_transactions sejam
(integer)
X X 5 Inicialização tão grandes quanto max_connections, para
evitar falhas desnecessárias na etapa de
preparação.
Aumentando este parâmetro fará o PostgreSQL
requisitar mais memória compartilhada ao
System V que a configuração padrão do seu
sistema operacional permite. Veja Seção 16.4.1
para informações sobre como ajustar estes
parâmetros.

Especifica a quantidade de memória utilizada Antigamente conhecida como sort_mem,
pelas operações internas de classificação e esta configuração teve seu nome trocado
tabelas de dispersão (hash tables), antes de para refletir o seu papel estendido em
alternar para arquivos temporários em disco. O governar não apenas ordenações.
valor é especificado em kilobytes, e o valor Work_mem é uma troca direta. Ajuste ele
padrão é 1024 kilobytes (1 MB). Deve ser para cima para: grandes bancos de
observado que, em uma consulta complexa, dados, consultas complexas, muita
podem ser executadas várias classificações ou memória RAM disponíveis. Ajuste para

Mapa do espaço livre

max_fsm_pages X X X X 1000 a 20000 Inicialização Define o número máximo de páginas de disco Um ajuste propício do FSM pode eliminar
(integer) int_max para as quais o espaço livre será acompanhado ou pelo menos adiar a necessidade de
no mapa de espaço livre compartilhado. São rodar um VACUUM FULL e REINDEX. A
consumidos seis bytes de memória melhor forma de configurar isto é a
compartilhada para cada encaixe de página. O seguinte:
valor definido deve ser maior que 16 *
1)Entenda que a freqüência de VACUUM
max_fsm_relations. O valor padrão é 20000.
(regular) do seu banco de dados é
Somente pode ser definido na inicialização do
baseado na atividade de escrita;
servidor.
2)Rode o banco de dados sobre carga de
produção normal, e rode o VACUUM
VERBOSE ANALYZE ao invés do
VACUUM, gravando a saída em um
arquivo.
3)Calcule o número máximo de páginas
reparadas entre os VACUUMs baseado
na saída e utilize-o.
Alternativamente, se você estiver
utilizando o Autocacuum, você pode se
basear como uma porcentagem do total
de páginas do seu banco de dados, para
casar com a porcentagem do
autovacuum. Pouca memória é requerida
por página (cerca de 6 bytes por página),
então é melhor ser generoso do que
avarento.
Favor notar que bancos de dados com
grandes “picos” de atividade (surtos de 1
milhão de atualizações tanto para
minutos ou horas) este número pode ser
impossível de ajustar perfeitamente.
Linhas inseridas não são significativas
para FSM. Finalmente, se o seu servidor
de banco de dados tem pouca RAM,
aumentar FSM para os valores
necessários pode ser contra-produtivo.

max_fsm_relatio X X X X 1000 Inicialização Define o número máximo de relações (tabelas e Poucos usuários vão precisar ajustar este
ns (integer) índices) para as quais o espaço livre será número, mas é melhor checar. Você deve
acompanhado no mapa de espaço livre ter ao menos tantas FSM_relations
compartilhado. São consumidos, quantas tabelas em todos os seus bancos
aproximadamente, 50 bytes de memória de dados, incluindo o banco de dados de

compartilhada por cada encaixe. O valor padrão modelo e o esquema de sistema. O
é 1000. Somente pode ser definido na PostgreSQL desenvolve uma performance
inicialização do servidor. ímpar uma vez que não se tenha
FSM_relations o suficiente.
X X X X
Utilização de Recursos do Cerne

max_files_per_pr 10 a 1000 Inicialização Define o número máximo permitido de arquivos Para constar, mais utilizado no BSD. Não
ocess (integer) int_max abertos simultaneamente por cada subprocesso se preocupe com ele a não ser que você
servidor. O valor padrão é 1000. Se o núcleo receba a mensagem “too many files”.
tiver um limite de segurança por processo, não
é necessário se preocupar com esta definição.
Entretanto, em algumas plataformas
(notadamente a maioria dos sistemas BSD), o
núcleo permite que processos individuais abram
muito mais arquivos que o sistema pode
suportar, quando um grande número de
processos tenta abrir esta quantidade de
arquivos ao mesmo tempo. Se for vista a
mensagem de erro quot;Muitos arquivos abertosquot;
deve-se tentar reduzir esta definição.

preload_libraries X Diretório Inicialização Especifica uma ou mais bibliotecas Isto é útil apenas para bancos de dados
(string) compartilhadas a serem pré-carregadas durante específicos com propósitos
a inicialização do servidor. Pode ser chamada, especializados. Por exemplo, o
opcionalmente, uma função de inicialização sem mapeamento do banco de dados pode ter
parâmetros para cada biblioteca. Para um pequeno de performance com a pré-
especificá-la deve ser adicionado dois-pontos e o carga as bibliotecas GIS. Para a maioria
nome da função de inicialização após o nome da dos sistemas, é melhor deixar isto vazio.
biblioteca. Por exemplo
'$libdir/minha_bib:minha_bib_inic' faz com que
minha_bib seja pré-carregada e minha_bib_inic
seja executada. Para carregar mais de uma
biblioteca, os nomes devem ser separados por
vírgula. Se minha_bib ou minha_bib_inic não for
encontrada, a inicialização do servidor não será
bem-sucedida.
As bibliotecas de linguagem procedural do
PostgreSQL são pré-carregadas desta maneira,
usualmente utilizando a sintaxe
'$libdir/plXXX:plXXX_init', onde XXX é pgsql,
perl, tcl ou python.
Fazendo a pré-carga da biblioteca

compartilhada (e a inicializando, se for
aplicável), ganha-se o tempo de inicialização da
biblioteca quando a biblioteca é utilizada pela
primeira vez. Entretanto, pode aumentar
ligeiramente o tempo para inicializar cada novo
processo servidor, mesmo que o processo nunca
utilize a biblioteca. Portanto, este parâmetro só
é recomendado para bibliotecas utilizadas pela
maioria das sessões.
Se uma biblioteca específica não é encontrada,
o servidor vai falhar na inicialização.
Todas as bibliotecas suportadas pelo
PostgreSQL possuem um “bloco mágico” que é
checado para garantir a compatibilidade. Por
esta razão, bibliotecas não-PostgreSQL não
podem ser carregadas desta forma.

Esta configuração é extremamente
valiosa quando estiver realizando o
Retardo do VACUUM baseado no custo

vacuum em grandes tabelas que de outra
A quantidade de tempo, em milissegundos, que forma iriam concorrer pela E/S por
o processo adormece quando o custo limite é longos períodos e bloquear numerosas
excedido. O valor padrão é 0, que desabilita a consultas. Ativar o o vacuum_delay,
funcionalidade de retardo do VACUUM baseado essencialmente quebra o vacuum em uma
no custo. Valores positivos habilitam o retardo grande tabela em segmentos definidos
vacuum_cost_de Tempo de do VACUUM baseado no custo. Deve ser como quantidades de trabalhos
lay (integer)
X X X 0
execução observado que em muitos sistemas a resolução específicos, entre o adormecimento do
efetiva de adormecimento é de 10 vacuum e o tempo definido nesta
milissegundos; definir vacuum_cost_delay com configuração. Isto tem o efeito final de
um valor que não é múltiplo de 10, pode ter o aumentar o tempo requerido pelo
mesmo resultado que definir com o próximo vacuum, possivelmente em alguns
múltiplo de 10 maior que o valor especificado. múltiplos, mas reduzindo o impacto
global no sistema do vacuum, em até
85%. Valores razoáveis para o atraso
estão entre 50ms e 200ms.
O custo estimado para executar o VACUUM em
um buffer encontrado no buffer cache Esta configuração deverá provavelmente
vacuum_cost_pa Tempo de compartilhado. Representa o custo para
ge_hit (integer)
X X X 1
execução
ser deixada como está em favor de
bloquear o buffer pool, examinar a tabela hash manipular o vacuum_cost_limit.
compartilhada, e varrer o conteúdo da página.

O custo estimado para executar o VACUUM em
um buffer que precisa ser lido no disco.
vacuum_cost_pa Representa o esforço para bloquear o buffer Esta configuração deverá provavelmente
Tempo de
ge_miss X X X 10
execução pool, examinar a tabela hash compartilhada, ler ser deixada como está em favor de
(integer) o bloco desejado no disco e varrer o seu manipular o vacuum_cost_limit.
conteúdo.

O custo estimado cobrado quando o VACUUM
vacuum_cost_pa modifica um bloco que foi limpo anteriormente. Esta configuração deverá provavelmente
Tempo de Representa a E/S adicional necessária para
ge_dirty X X X 20
execução
ser deixada como está em favor de
(integer) descarregar no disco novamente um bloco que manipular o vacuum_cost_limit.
foi limpo anteriormente.

O custo acumulado que faz com que o processo
executando o VACUUM adormeça.
Nota: Existem determinadas operações que Diminua isto para quebrar o vacuum em
prendem bloqueios críticos e que devem, mais “segmentos”. Uma combinação
portanto, terminar o mais rápido possível. O bastante agressiva seria um

Especifica o retardo entre rodadas de atividade
para escritor de segundo plano. A cada rodada o
Escrita em segundo Plano

escritor escreve uma quantidade de buffers
sujos (controlado pelos parâmetros mostrados a
seguir). Os buffers selecionados são sempre os O escritor de segundo plano é uma nova
usados menos recentemente entre os buffers funcionalidade desenvolvida para aliviar
sujos atuais. Em seguida adormece por a carga dos checkpoints.
bgwriter_delay bgwriter_delay milissegundos e repete a Nós ainda estamos realizando testes com
(integer)
X X X 200 Inicialização operação. Deve ser observado que em muitos as configurações do bgwriter no OSDL;
sistemas a resolução efetiva do adormecimento não há nenhuma recomendação até o
é de 10 milissegundos; definir bgwriter_delay momento.
com um valor que não é múltiplo de 10, pode ter
o mesmo resultado que definir com o próximo
múltiplo de 10 maior que o valor especificado.
servidor, ou no arquivo postgresql.conf.

A cada rodada não será escrito mais que esta
percentagem de buffers sujos no momento (as Nós ainda estamos realizando testes com
bgwriter_percent frações são arredondadas para o próximo as configurações do bgwriter no OSDL;
(integer)
X 1 Inicialização número inteiro de buffers acima). Somente pode não há nenhuma recomendação até o
ser definido na inicialização do servidor, ou no momento.
arquivo postgresql.conf.

A cada rodada não será escrito mais que esta Nós ainda estamos realizando testes com
bgwriter_maxpa quantidade de buffers sujos. Somente pode ser as configurações do bgwriter no OSDL;
ges (integer)
X 100 Inicialização definido na inicialização do servidor, ou no não há nenhuma recomendação até o
arquivo postgresql.conf. momento.

Para reduzir a probabilidade do processo do
servidor precisar realizar suas próprias escritas,
o escritor de segundo plano tenta gravar buffers
que serão provavelmente reciclados logo. Em
bgwriter_lru_per cada rodada, ele examina o
cent (floating X X 1,0 Inicialização bgwriter_lru_percent dos buffers que estão mais
point) próximos de serem reciclados e escreve naquele
que estiver sujo. O valor padrão é 1.0 (este é um
porcentual com o número total de
shared_buffers).

Em cada rodada, não mais que estes buffers
bgwriter_lru_ma serão gravados como resultado da busca aos
xpages (integer)
X X 5 Inicialização
buffers próximos de serem reciclados.

Log de escrita prévia (WAL)
Configurado
em
fsync (boolean) X X X X on / off on Inicialização -F Se o valor deste parâmetro for on, o servidor Desligue o WAL (fsync=off) apenas em
PostgreSQL utilizará a chamada de sistema banco de dados somente para leitura ou
fsync() em vários lugares para ter certeza que onde o banco de dados pode ser
as atualizações estão fisicamente escritas no restaurado a partir de um software
disco. Isto garante que o agrupamento de externo. Enquanto RAID mais No-breacks
bancos de dados vai ser recuperado em um podem fazer muito para proteger seus
estado consistente após um problema de dados, desligando fsync, significa que
máquina ou do sistema operacional você irá restaurar a partir do backup em
caso de falha de hardware ou energia.
Entretanto, a utilização de fsync() produz uma
degradação de desempenho: quando a Por outro lado, o WAL impões uma
transação é efetivada, o PostgreSQL tem de penalidade significativa a escrita em
aguardar o sistema operacional descarregar o banco de dados, especialmente em
log de escrita prévia no disco. Quando fsync sistemas com apenas um disco.
está desabilitado, o sistema operacional pode Essencialmente você está dobrando a
desempenhar da sua melhor maneira a quantidade de leitura/gravação requerida
quot;buferizaçãoquot;, ordenação e retardo na escrita. por uma atualização e ainda requerendo
Isto pode produzir uma melhora significativa no que você desabilite as funcionalidades de
desempenho. Porém, no caso de uma queda do cache de disco do seu hardware e SO.
sistema, podem ser perdidos, em parte ou por Então, se seus dados são dispensáveis,
inteiro, os resultados das poucas últimas desligar o Fsync é uma boa consideração.
transações efetivadas. No pior caso, os dados
Se o WAL estiver desligado, o resto
podem ficar corrompidos de uma forma
destas opções nesta seção são
irrecuperável (Para esta situação a queda do
irrelevantes.
servidor de banco de dados não é um fator de
risco, somente há risco dos dados ficarem
corrompidos no caso de queda do sistema
operacional).
Devido aos riscos envolvidos não existe uma
definição universalmente aceita para fsync.
Alguns administradores sempre desabilitam
fsync, enquanto outros só desabilitam para
cargas de dado pesadas, onde claramente existe

um ponto de recomeço se algo de errado
acontecer, enquanto outros administradores
sempre deixam fsync habilitado. O valor padrão
para fsync é habilitado, para obter o máximo de
confiabilidade. Havendo confiança no sistema
operacional, na máquina, e nos utilitários que
acompanham (ou na bateria de reserva), pode-
se levar em consideração desabilitar fsync.
servidor, ou no arquivo postgresql.conf.
Se você desligar este parâmetro, desligue
também o full_page_writes.

Método utilizado para obrigar a colocar as
atualizações do WAL no disco. Os valores
possíveis são fsync (chamada à função fsync() a
cada efetivação), fdatasync (chamada à função
fdatasync() a cada efetivação), open_sync
(escreve os arquivos WAL com a opção O_SYNC
da função open()), e open_datasync (escreve A chamada de sistema utilizada para
arquivos WAL com a opção O_DSYNC do sincronizar o WAL no disco. O padrão
fsync, open()). Nem todas estas opções estão deve ser ajustado para cada SO baseado
fdatasyn disponíveis em todas as plataformas. Somente na documentação do SO, nas nenhum
Varia
c, pode ser definido na inicialização do servidor, teste profundo de comparação foi
wal_sync_method com a
(string)
X X X X open_syn
platafor
Inicialização ou no arquivo postgresql.conf. postado. É possível que trocar de método
c, pode melhorar a velocidade de escrita da
ma open_datasync (escreve os arquivos WAL files
open_dat sua plataforma, mas não brinque com isto
async com open() opção O_DSYNC) a não ser que você tenha tempo e
fdatasync (chama fdatasync() em cada recursos para rodar testes comparativos
commit) e de falhas.
fsync_writethrough (chama fsync() em cada
commit, forçando escrever através de
qualquer cache de escrita em disco)
fsync (chama fsync() em cada commit)
open_sync (escreve os arquivos WAL com
open() opção O_SYNC)
full_page_writes X X on / off on Inicialização Quando este parâmetro está ligado, o servidor
(boolean) PostgreSQL grava todo o conteúdo de cada
página de disco para o WAL durante a primeira
modificação daquela página após o checkpoint.
Isto é preciso porque a gravação da página que

está em progresso durante uma queda de
sistema está apenas parcialmente completada,
deixando uma página em disco que contém um
misto de dados novos e velhos. A mudança em
nível de linha normalmente armazenada no WAL
não será o suficiente para restaurar
completamente a página durante uma
recuperação pós queda. Armazenando a imagem
completa da página garante que a página será
corretamente restaurada, mas ao preço de
aumentar o volume de dados que precisam ser
gravados no WAL. (Porque a repassagem do
WAL sempre começa a partir do checkpoint, é
suficiente fazer custo durante a primeira
alteração em cada página após o checkpoint.
Assim, uma forma de reduzir o custo da
gravação da página cheia é aumentar o
parâmetro de intervalo do checkpoint.
Desligando esta opção resulta numa velocidade
normal de operação, mas poder levar a
corrupção do banco de dados após uma falha no
Sistema Operacional ou energia. O risco é
semelhante a desligar o fsync, apesar de menor.
Deve ser seguro desligar este parâmetro se você
tiver um hardware (como uma controladora de
discos com bateria) ou software de sistema de
arquivos que reduza o risco de gravações
parciais de páginas em um nível aceitável (ex.
ReiserFS 4).
Desligar este parâmetro não afeta o uso do WAL
archiving para point-in-time-recovery (PITR)
(veja a Seção 23.3).

Número de buffers de página de disco alocados Aumentar este parâmetro tem resultado
na memória compartilhada para os dados do num efeito mínimo, mesmo em um
WAL. O valor padrão é 8. Esta definição sistema OLTP muito ocupado. Se você
4a somente precisa ser grande o suficiente para
wal_buffers (integer) X X X X max_int
8 Inicialização sabe que terá transações muito longas,
conter a quantidade de dados do WAL gerados você poderá aumentar isto só para estar
por uma transação típica. Somente pode ser seguro (para 16 a 64), mas foque o ajuste
definido na inicialização do servidor. mais em checkpoint_segments.

Retardo entre a escrita do registro de efetivação
no buffer do WAL e a descarga do buffer no
disco, em microssegundos. Um retardo maior Estas duas opções são configuradas
que zero permite que seja feita apenas uma juntas para um grande volume de
chamada de sistema fsync() para várias pequenas transações. Quando ajustadas,
transações efetivadas, se a carga do sistema for elas permitem um grupo de diferentes
alta o suficiente para que outras transações transações serem enviadas ao disco ao
fiquem prontas para efetivar dentro do intervalo mesmo tempo, com um possível ganho
commit_delay 0a Tempo de
(integer)
X X X X 100000
0
execução especificado. Entretanto, este retardo é significativo de performance. Contudo,
simplesmente desperdício se nenhuma outra este é uma troca ao esperar alguns
transação ficar pronta para efetivar. Portanto, o milissegundos extras em cada transação.
retardo somente é realizado se pelo menos Se você quiser testar se isto aumenta a
outras commit_siblings transações estiverem performance para você, um bom ponto de
ativas no instante que o processo servidor partida é um commit_delay de 500 (½
escrever seu registro de efetivação. O valor milissegundo).
padrão é zero (nenhum retardo).

Se estiver usando o commit_delay, você
vai querer alterar esta opção dependendo
do comprimento médio das transações
Número mínimo de transações simultâneas no seu sistema. Se as transações forem
abertas requerido para realizar o retardo muito curtas (comandos de
commit_siblings Tempo de commit_delay. Um valor maior torna mais atualização/inserção simples de uma
(integer)
X X X X 1 a 1000 5
execução provável que pelo menos uma outra transação linha) então você irá utilizar valores
fique pronta para efetivar durante o período do baixos como um commit simultâneo é
retardo. O valor padrão é 5. mais provável. Se as transações são
longas, você vai querer aumentar isso
para evitar o uso desnecessário do
commit_delay.
checkpoint_segments X X X X 1a 3 Inicialização Distância máxima entre pontos de controle Esta é a opção mais efetiva para lidar
(integer) int_max automático do WAL, em segmentos de arquivo com grandes atualizações, carga de
de log (cada segmento possui normalmente 16 dados e atividade pesada de OLTP. Para
MB). O valor padrão é 3. Somente pode ser qualquer sistema com pesada atividade
definido na inicialização do servidor, ou no de escrita, você deverá aumentar isto
arquivo postgresql.conf. para ao menos 8; em sistemas com
grandes cargas (como a carga de alguns
GB de dados), algo em torno de 128 (e
nós usamos 256 para testar o DBT2).
Contudo, isto requer um montante
significativo de espaço em disco para o
xlog ((2 x segmentos + 1 ) x 16 MB, para

Revisão do postgresql.conf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (6)

Destacado

Destacado (20)

Similar a Revisão do postgresql.conf

Similar a Revisão do postgresql.conf (9)

Más de Fabio Telles Rodriguez

Más de Fabio Telles Rodriguez (20)

Revisão do postgresql.conf