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;
