AFAIK is geen server-side batching in de fe/be protocol
, dus PgJDBC kan het niet gebruiken. . Bijwerken :Nou, ik had het mis. PgJDBC (nauwkeurig vanaf 9.3) doet stuur batches query's naar de server als het geen gegenereerde sleutels hoeft op te halen . Het plaatst gewoon een aantal zoekopdrachten in de verzendbuffer zonder na elke individuele zoekopdracht te synchroniseren met de server.
Zie:
- Probleem #15:batchverwerking inschakelen bij het retourneren van gegenereerde sleutels
- Probleem #195:PgJDBC pijplijn batches die gegenereerde sleutels retourneren
Zelfs wanneer gegenereerde sleutels worden gevraagd de uitgebreide query protocol wordt gebruikt om ervoor te zorgen dat de vraagtekst niet elke keer hoeft te worden verzonden, alleen de parameters.
Eerlijk gezegd is JDBC batching in ieder geval geen geweldige oplossing. Het is gemakkelijk te gebruiken voor de app-ontwikkelaar, maar behoorlijk suboptimaal voor prestaties omdat de server nog steeds elke instructie afzonderlijk moet uitvoeren - hoewel niet parseren en plan ze afzonderlijk, zolang u voorbereide verklaringen gebruikt.
Als autocommit is ingeschakeld, zullen de prestaties absoluut zielig zijn omdat elke instructie een commit activeert. Zelfs als autocommit is uitgeschakeld, zullen veel kleine overzichten niet bijzonder snel zijn, zelfs als u de vertragingen voor retourvluchten zou kunnen elimineren.
Een betere oplossing voor veel eenvoudige UPDATE s kunnen zijn:
COPYnieuwe gegevens in eenTEMPORARYofUNLOGGEDtafel; en- Gebruik
UPDATE ... FROMomUPDATEmet eenJOINtegen de gekopieerde tabel
Voor KOPIE, zie de PgJDBC-documenten
en de COPY documentatie in de serverdocumenten
.
Je zult vaak merken dat het mogelijk is om dingen aan te passen, zodat je app niet al die individuele UPDATE hoeft te verzenden is helemaal niet.