Por que executar esse comando restore demorou tanto?

Question

Estou usando o PostgreSQL 9.1 no Ubuntu 12.04. A máquina de desenvolvimento tem 2GB de RAM e é um Centrino Duo.

O comando Backup é pg_dump e leva menos de 5 segundos para ser executado a partir do terminal.

Mas minha restauração é feita assim:

/usr/bin/psql --host localhost --port 5432 --username "postgres" --quiet "dbHRS" < "t2"

O arquivo de texto "t2" tem cerca de 5000 linhas de inserções. Mas demora cerca de 2 minutos para ser concluído.

Por que demora tanto? Há algo que eu possa fazer para torná-lo mais rápido?

INFORMAÇÃO ADICIONAL: O backup foi feito assim:

/usr/bin/pg_dump --host localhost --port 5432 --username "postgres" --role "mizk" --no-password  --format plain --data-only --inserts --column-inserts --verbose --file "abc" "dbHRS"

Portanto, o arquivo abc contém JUST A SET OF INSERT QUERIES. Isso é tudo. Nenhum procedimento armazenado, nenhum gatilho ...

Não posso aceitar a lentidão para restaurar. O que é estranho é que quando copio e colo o conteúdo do arquivo de texto em uma janela de consulta no PG-Admin, é bem rápido. Apenas alguns segundos. Então, acho que tem a ver com a maneira como o comando psql funciona. Talvez eu esteja errado.

    

Answer 1

Não sabendo exatamente o que está sendo feito, só posso falar em geral:

• As leituras são simplesmente leituras da memória ou do disco.
• As gravações precisam verificar as restrições, os acionadores de ação e, em seguida, gravar no disco. Geralmente dentro de uma transação que precisa ser configurada, acionada e depois limpa. E depois há invalidação de cache.
• A maioria dos discos (e seus sistemas de arquivos) lêem muito mais rapidamente do que escrevem.

Não me surpreende que uma restauração demore mais do que um backup, mas se você realmente achar que ela é erroneamente longa, benchmark suas consultas e descobrir qual é o problema.

    

Answer 2

Como Oli mencionou, as gravações levam mais tempo. Um exemplo do mundo real é um banco de dados que eu tive que migrar para um cliente. Era muito grande e demorou cerca de 24 horas para executar o despejo completo.

A importação levou cerca de 3 vezes mais tempo, no entanto. Com o seu computador de teste, soa como uma máquina de mesa, significando apenas um disco rígido (sem RAID). Se você continuar tendo problemas depois de comparar suas consultas, poderá ver que tipo de disco rígido está na máquina. Velocidades de rotação mais rápidas serão melhores neste aplicativo, portanto, se você tiver uma unidade de 5400 RPM, adicionar uma unidade especificamente para SQL é uma opção. Se você tem uma unidade de 7200 RPM, é um pouco melhor, mas você ainda pode querer atualizar.

Dependendo do tamanho do banco de dados, eles fazem algumas unidades SSD de pequena capacidade que não são muito caras. Se você definir seu SQL para rodar nele, ele deverá melhorar o desempenho. Junto com isso, sua configuração atual provavelmente tem o sistema operacional e o banco de dados no mesmo disco rígido. Dividir esses itens deve aumentar o desempenho.