Otimize o PostgreSQL para obter muitas atualizações INSERTS e bytea

O que temos (software):

• PostrgeSQL 9.3 com configuração básica (sem alterações postgresql.conf)
• Windows 7 de 64 bits

Hardware:

• Intel Core i7-3770 3.9 Ghz
• 32 Gb de RAM
• Unidade WDC WD10EZRX-00L4HBAta (1000Gb, SATA III)

Então, temos que carregar no DB aprox. 100.000.000 linhas com coluna bytea e mais 500.000.000 linhas simples (sem LOBs). Existem 2 varcharíndices na 1ª tabela (com 13, 19 comprimentos) e 2 varcharíndices na 2ª tabela (18, 10 comprimentos). Também existem sequências para geração de ID para cada tabela.

Até agora, essas operações estão funcionando com 8 conexões em paralelo com o tamanho de lote de 50 JDBC. A figura abaixo demonstra a carga do sistema: é de carga zero nos postgresqlprocessos. Após 24 horas de carregamento, carregamos apenas 10.000.000 de linhas, o que é um resultado muito lento.

Estamos solicitando ajuda no ajuste da PostrgreSQLconfiguração para:

1) para carregamento ultra-rápido dessa quantidade de dados, é uma operação única, portanto pode ser uma configuração temporária

2) para o modo de produção, para executar um número moderado de SELECTs nessas 2 tabelas por seus índices, sem associação e sem classificação.

Para obter insertdesempenho, consulte acelerando o desempenho da inserção no PostgreSQL e inserção em massa no PostgreSQL .

Você está perdendo seu tempo com o lote do JDBC insert. O PgJDBC não faz nada útil com insertlotes, apenas executa cada instrução . <- Isso não é mais verdade nas versões mais recentes do PgJDBC, que agora podem criar instruções preparadas em lote para reduzir consideravelmente os tempos de ida e volta. Mas ainda é melhor:

Use em COPYvez disso; consulte Cópia em lote PgJDBC e o CopyManager. Quanto ao número de carregadores simultâneos: mencione alguns por disco, se as operações estiverem vinculadas à E / S do disco. Oito é provavelmente o máximo que você deseja.

Para o seu "modo de produção", sugiro carregar uma amostra de dados, configurar as consultas que você espera executar e usar explain analyzepara investigar o desempenho. Apenas para fins de teste, use os enable_parâmetros para explorar diferentes seleções de plano. Defina os parâmetros de custo planejador de comandos ( random_page_cost, seq_page_cost, effective_cache_size, etc.) de forma apropriada para o seu sistema, e certifique-se shared_buffersestiver definida de forma adequada. Continue a monitorar enquanto adiciona uma carga de trabalho de produção simulada, usando o auto_explainmódulo, a log_min_duration_statementconfiguração, a pg_stat_statementsextensão etc.

Para detalhes, consulte o manual do usuário do PostgreSQL. Sugiro voltar aqui quando você tiver um problema mais concreto com os explain analyzedetalhes da execução da consulta, etc.