PgJDBC tiene algunas limitaciones con respecto a los lotes:
-
Todos los valores de solicitud y todos los resultados deben acumularse en la memoria. Esto incluye resultados grandes de blob/clob. Por lo tanto, la memoria libre es el principal factor limitante para el tamaño del lote.
-
Hasta PgJDBC 9.4 (aún no publicado) , los lotes que devuelven claves generadas siempre hacen un viaje de ida y vuelta para cada entrada , por lo que no son mejores que las ejecuciones de sentencias individuales.
-
Incluso en 9.4, los lotes que devuelven claves generadas solo ofrecen un beneficio si los valores generados tienen un tamaño limitado. Un único
text,byteao sin restriccionesvarcharcampo en el resultado solicitado obligará al conductor a hacer un viaje de ida y vuelta para cada ejecución .
El beneficio del procesamiento por lotes es una reducción en los viajes de ida y vuelta de la red. Por lo tanto, tiene mucho menos sentido si su base de datos es local para su servidor de aplicaciones. Hay un rendimiento decreciente a medida que aumenta el tamaño del lote, porque el tiempo total que se tarda en esperar en la red se reduce rápidamente, por lo que a menudo no es estresante tratar de hacer que los lotes sean lo más grandes posible.
Si está cargando datos de forma masiva, considere seriamente usar el COPY API en su lugar, a través de CopyManager de PgJDBC , obtenido a través de PgConnection interfaz. Le permite transmitir datos similares a CSV al servidor para una carga masiva rápida con muy pocos viajes de ida y vuelta de cliente/servidor. Desafortunadamente, está muy poco documentado:no aparece en los documentos principales de PgJDBC, solo en los documentos de la API
.
