PgJDBC heeft enkele beperkingen met betrekking tot batches:
-
Alle aanvraagwaarden en alle resultaten moeten in het geheugen worden verzameld. Dit omvat grote blob/clob-resultaten. Dus vrij geheugen is de belangrijkste beperkende factor voor de batchgrootte.
-
Tot PgJDBC 9.4 (nog niet vrijgegeven) , batches die gegenereerde sleutels retourneren, doen altijd een retourtje voor elke invoer , dus ze zijn niet beter dan uitvoeringen van afzonderlijke instructies.
-
Zelfs in 9.4 bieden batches die gegenereerde sleutels retourneren alleen een voordeel als de gegenereerde waarden beperkt zijn. Een enkele
text,byteaof onbeperktvarcharveld in het gevraagde resultaat dwingt de chauffeur om een heen- en terugreis te maken voor elke uitvoering .
Het voordeel van batching is een vermindering van netwerkrondreizen. Het heeft dus veel minder zin als uw DB lokaal is voor uw app-server. Er is een afnemend rendement naarmate de batchgrootte toeneemt, omdat de totale tijd die nodig is voor netwerkwachten snel afneemt, dus het is vaak geen werkstress om batches zo groot mogelijk te maken.
Als u gegevens in bulk laadt, overweeg dan serieus om de COPY . te gebruiken API in plaats daarvan, via PgJDBC's CopyManager , verkregen via de PgConnection koppel. Hiermee kunt u CSV-achtige gegevens naar de server streamen voor snelle bulklading met zeer weinig client/server-round trips. Helaas is het opmerkelijk ondergedocumenteerd - het verschijnt helemaal niet in de belangrijkste PgJDBC-documenten, alleen in de API-documenten
.