Estou usando o postgreSQL 7.4.
Eu tenho uma grande tabela, chame-a de table_a:
key1 INT NOT NULL,
key2 INT NOT NULL,
data INT NOT NULL,
itstamp INT NOT NULL DEFAULT (date_part('EPOCH'::text, (timeofday())::timestamp without time zone))::INTEGER
e uma tabela que resume a hora da última atualização para key1, chame-a de table_b:
key1 INT NOT NULL,
max_itstamp INT NOT NULL
Criei uma função trigger no plpgsql para atualizar ou inserir linhas na table_b conforme necessário:
CREATE OR REPLACE FUNCTION table_b_update() RETURNS TRIGGER AS '
DECLARE
l_key1 INT;
l_itstamp INT;
BEGIN
l_key1 := new.key1;
l_itstamp := new.itstamp;
PERFORM TRUE FROM table_b WHERE key1=l_key1;
IF NOT FOUND THEN
INSERT INTO table_b(key1, max_itstamp) values (l_key1, l_itstamp);
ELSE
UPDATE table_b SET max_itstamp=l_itstamp WHERE key1=l_key1;
END IF;
RETURN NULL;
END'
LANGUAGE plpgsql IMMUTABLE;
e então anexei um gatilho à table_a:
CREATE TRIGGER table_a_trigger1 AFTER INSERT OR UPDATE ON table_a FOR EACH ROW
EXECUTE PROCEDURE table_b_upate();
Agora, o tempo para inserir novos dados em table_a cresce de forma incremental. A pegada de arquivo de table_b cresce de forma constante.
Usei comandos RAISE NOTICE na função para confirmar que a instrução If causa um UPDATE e não um INSERT após a primeira chamada por tecla.
Como o tempo de inserção da tabela_a aumenta para cada INSERT, tentei um VACUUM FULL na tabela_b. O tempo de inserção table_a foi reduzido consideravelmente. O tamanho do arquivo para table_b foi reduzido consideravelmente. Após o VACUUM FULL o tempo de inserção table_a voltou a crescer. Eu não quero fazer um VACUUM FULL após cada INSERT em table_a embora.
É possível que o UPDATE esteja realmente fazendo um DELETE e INSERT na table_b?
O PostgreSQL realmente não faz atualizações, ele faz o equivalente a excluir e inserir em termos de como as faz. Ele deixa a versão antiga da linha no lugar e cria uma nova versão que todas as transações futuras verão. Eventualmente, o vácuo recupera o antigo espaço de linha para reutilização. Um conselho, atualize imediatamente para uma versão suportada. 7.4 é MUITO antigo, não é mais suportado e tem erros conhecidos de consumo de dados que nunca serão corrigidos. Eu recomendo ir direto para 9.0 e pesquisar os problemas com casts implícitos removidos, que serão o maior problema. Tivemos que corrigir três consultas em nosso aplicativo quando fomos para 8.3, a primeira versão para remover conversões implícitas.
Não tenho 7.4 para testar, mas estou supondo:
vacuum full
compacto de mesaupdate
, a nova versão da linha (consulte MVCC ) é empurrada no final da pilha antes que a antiga seja removida por umvacuum
Veja aqui os documentos que explicam isso com mais detalhes, mas a solução simples é não executar
vacuum full
- apenasvacuum
. Em seguida, sua tabela provavelmente se estabelecerá em um estado estável, onde 'buracos' nos dados são deixados e podem ser usados por atualizações posteriores.Quanto ao "tempo de inserção", estou surpreso com seus resultados. Minha expectativa seria que o
insert
tempo fosse mais lento após umvacuum full
- mas se todos os blocos estiverem no cache, a sobrecarga de encontrar espaço livre dentro do bloco atual pode ser maior do que adicionar a nova linha no final da pilha, mesmo que o número de blocos acessados é maior