PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Fator de preenchimento para um índice sequencial que é PK

FILLFACTOR


Com apenas INSERT e SELECT você deve usar um FILLFACTOR de 100 em toda parte.

Não faz sentido deixar espaço de manobra por bloco de memória se você não for "mexer" com UPDATE s.

O mecanismo por trás de FILLFACTOR é muito simples. INSERT s apenas preenche cada página de dados (geralmente blocos de 8 kb) até a porcentagem declarada pelo FILLFACTOR contexto. Além disso, sempre que você executar VACUUM FULL ou CLUSTER na mesa, o mesmo espaço de manobra por bloco é restabelecido. Idealmente, isso permite UPDATE s para armazenar novas versões de linha na mesma página de dados, o que pode fornecer um aumento substancial de desempenho ao lidar com muitos UPDATE s. Também benéfico em combinação com H.O.T. atualizações :

Se houver não atualizações, não perca espaço para isso e defina FILLFACTOR = 100 .

Fonte básica de informações:o manual sobre CREATE TABLE ou CREATE INDEX .

Outras otimizações


Mas você pode fazer outra coisa - já que você parece ser um otário para otimização ... :)
CREATE TABLE dev_transactions
( transaction_id serial PRIMARY KEY,
  gateway integer NOT NULL,
  moment timestamp NOT NULL,
  transaction_type smallint NOT NULL,
  status smallint NOT NULL,
  device integer NOT NULL,
  controler smallint NOT NULL,
  token integer,
  et_mode character(1));

Isso otimiza sua tabela em relação ao alinhamento de dados e evita preenchimento para um servidor típico de 64 bits e economiza alguns bytes, provavelmente apenas 8 bytes em média - você normalmente não pode espremer muito com "column tetris:

Além disso, mantenha NOT NULL colunas no início da tabela para um bônus de desempenho muito pequeno.

Além disso, sua tabela tem 9 colunas . Isso significa um acréscimo de 8 bytes para o bitmap NULL estendido - que caberia no bitmap NULL inicial de 1 byte para apenas 8 colunas .
Se você definir et_mode e token NOT NULL , todas as colunas são NOT NULL e o bitmap NULL é usado, liberando 8 bytes.
Isso funciona mesmo por linha se você não declarar as colunas NOT NULL . Se todas as colunas tiverem valores, não haverá bitmap NULL para esta linha. No seu caso, isso leva ao efeito paradoxal de que o preenchimento de valores para et_mode e token pode tornar seu tamanho de armazenamento menor ou pelo menos continue o mesmo:

Fonte básica de informações:o manual sobre armazenamento físico de banco de dados .

Compare o tamanho das linhas (preenchidas com valores) com sua tabela original para obter uma prova definitiva:
SELECT pg_column_size(t) FROM dev_transactions t;