As palavras-chave aqui são:
- "fortemente atualizado"
- "na mesa por 2-3 horas".
O ponto 1. é uma indicação para um fator de preenchimento mais baixo, enquanto 2. é o oposto. Ajuda o desempenho se várias versões de linha forem armazenadas na mesma página de dados. As atualizações HOT conseguiriam isso. Leia aqui ou aqui . Eles precisam de algum espaço de manobra na página de dados - como tuplas mortas ou espaço reservado por fillfactor
<100. Mas eles só podem fazer o que precisam , se nenhum índice envolver qualquer uma das colunas atualizadas , o que deve ser verdadeiro para o seu caso.
Outro fator importante aqui seria o tamanho da tupla (em comparação com o tamanho da sua página (que geralmente é de 8 kb). Mais detalhes nesta resposta relacionada:
Se o tamanho da tupla for 4 kb ou mais, a redução do fator de preenchimento seria inútil, pois nunca poderá haver mais de uma tupla em uma página de dados. Você também pode deixá-lo em 100
(que é o padrão de qualquer maneira). No entanto, alguns tipos de dados são "brindados" e armazenados fora de linha se excederem um limite de tamanho; portanto, as tuplas que exigem muito da relação principal são raras.
Faça o que fizer, VACUUM
será executado com frequência. E isso geralmente é uma coisa boa, eu não me preocuparia com isso. Você cria muitas tuplas mortas. VACUUM
identifica linhas mortas que não são mais visíveis para nenhuma transação aberta. O manual:
O formato padrão VACUUM
remove as versões de linha morta em tabelas e índices e marca o espaço disponível para reutilização futura .
Negrito ênfase minha.
Você pode jogar com configurações por tabela para o vácuo automático para acioná-lo com menos (ou mais) frequentemente apenas para esta tabela:
Os limites padrão e os fatores de escala são obtidos
postgresql.conf
, mas é possível substituí-los tabela por tabela ;
Negrito ênfase minha. Em particular com autovacuum_vacuum_threshold
eautovacuum_vacuum_scale_factor
. Correr VACUUM
muito pode realmente ser uma boa ideia, em vez de muito baixa fillfacter
. Isso depende dos padrões de acesso. Se todas as tuplas viverem, digamos, 3 horas e cada uma for atualizada várias vezes, eu ainda reduziria fillfactor
para algo como 50. Você terá que testar e encontrar o ponto ideal.
Alternativas
Tudo isso à parte, já que seus dados parecem voláteis, para começar: use uma UNLOGGED
tabela :
Os dados gravados em tabelas não registradas não são gravados no log write-ahead (consulte o Capítulo 29 ), o que os torna consideravelmente mais rápidos que as tabelas comuns. No entanto, eles não são à prova de falhas : uma tabela não registrada é truncada automaticamente após uma falha ou um desligamento não limpo. O conteúdo de uma tabela não registrada também não é replicado para servidores em espera.
Negrito ênfase minha. Não use isso se o servidor falhar e você ainda precisar dos dados posteriormente. Mas se estivermos falando sobre dados de sessão para aplicativos da web, esse pode ser um preço aceitável a ser pago.
Ou, ainda mais radical: use um armazenamento de valores-chave como o Redis, se você puder ficar sem os recursos e a segurança fornecidos por um RDBMS.