jdbc-Stapelleistung

AFAIK ist kein serverseitiges Batching im fe/be Protokoll , also kann PgJDBC es nicht verwenden. . Aktualisieren :Nun, ich habe mich geirrt. PgJDBC (genau ab 9.3) macht Stapel von Abfragen an den Server senden, wenn er keine generierten Schlüssel abrufen muss . Es stellt einfach eine Reihe von Abfragen in den Sendepuffer, ohne sich nach jeder einzelnen Abfrage mit dem Server zu synchronisieren.

Siehe:

• Problem Nr. 15:Batching aktivieren, wenn generierte Schlüssel zurückgegeben werden
• Problem Nr. 195:PgJDBC leitet keine Batches weiter, die generierte Schlüssel zurückgeben

Auch wenn generierte Schlüssel angefordert werden, wird die erweiterte Abfrage Protokoll wird verwendet, um sicherzustellen, dass nicht jedes Mal der Abfragetext gesendet werden muss, sondern nur die Parameter.

Ehrlich gesagt ist JDBC-Batching sowieso keine großartige Lösung. Es ist für den App-Entwickler einfach zu verwenden, aber ziemlich suboptimal für die Leistung, da der Server immer noch jede Anweisung einzeln ausführen muss – allerdings nicht parsen und planen sie einzeln, solange Sie vorbereitete Anweisungen verwenden.

Wenn Autocommit aktiviert ist, ist die Leistung absolut erbärmlich, da jede Anweisung einen Commit auslöst. Selbst wenn Autocommit ausgeschaltet ist, werden viele kleine Anweisungen nicht besonders schnell ausgeführt, selbst wenn Sie die Roundtrip-Verzögerungen eliminieren könnten.

Eine bessere Lösung für viele einfache UPDATE s können sein:

• COPY neue Daten in ein TEMPORARY oder UNLOGGED Tisch; und
• Verwenden Sie UPDATE ... FROM zu UPDATE mit einem JOIN gegen die kopierte Tabelle

Für COPY siehe die PgJDBC-Dokumentation und die COPY Dokumentation in der Serverdokumentation .

Sie werden oft feststellen, dass es möglich ist, Dinge zu optimieren, damit Ihre App nicht all diese individuellen UPDATE senden muss s überhaupt.