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;