O PgJDBC tem algumas limitações em relação aos lotes:

• 
  Todos os valores de solicitação e todos os resultados devem ser acumulados na memória. Isso inclui resultados grandes de blob/clob. Portanto, a memória livre é o principal fator limitante para o tamanho do lote.
  
• 
  Até o PgJDBC 9.4 (ainda não lançado) , os lotes que retornam as chaves geradas sempre fazem uma viagem de ida e volta para cada entrada , então eles não são melhores do que execuções de instruções individuais.
  
• 
  Mesmo na versão 9.4, os lotes que retornam as chaves geradas só oferecem um benefício se os valores gerados tiverem tamanho limitado. Um único text , bytea ou varchar irrestrito campo no resultado solicitado forçará o motorista a fazer uma viagem de ida e volta para cada execução .
  

O benefício do batching é uma redução nas viagens de ida e volta da rede. Portanto, há muito menos sentido se seu banco de dados for local para seu servidor de aplicativos. Há um retorno decrescente com o aumento do tamanho do lote, porque o tempo total gasto nas esperas da rede diminui rapidamente, então muitas vezes não é estressante tentar fazer os lotes tão grandes quanto possível.

Se você estiver carregando dados em massa, considere seriamente usar o COPY API em vez disso, via CopyManager do PgJDBC , obtido através do PgConnection interface. Ele permite que você transmita dados semelhantes a CSV para o servidor para carregamento em massa rápido com muito poucas viagens de ida e volta de cliente/servidor. Infelizmente, é notavelmente subdocumentado - não aparece nos documentos principais do PgJDBC, apenas nos documentos da API .