PgJDBC a quelques limitations concernant les lots :
-
Toutes les valeurs de requête et tous les résultats doivent être accumulés en mémoire. Cela inclut les résultats blob/clob volumineux. La mémoire libre est donc le principal facteur limitant pour la taille du lot.
-
Jusqu'à PgJDBC 9.4 (pas encore publié) , les lots qui renvoient les clés générées font toujours un aller-retour pour chaque entrée , elles ne valent donc pas mieux que les exécutions d'instructions individuelles.
-
Même dans la version 9.4, les lots qui renvoient des clés générées n'offrent un avantage que si les valeurs générées sont limitées en taille. Un seul
text,byteaouvarcharsans contrainte champ dans le résultat demandé obligera le conducteur à faire un aller-retour pour chaque exécution .
L'avantage du traitement par lots est une réduction des allers-retours sur le réseau. Il y a donc beaucoup moins d'intérêt si votre base de données est locale sur votre serveur d'applications. Le rendement diminue avec l'augmentation de la taille des lots, car le temps total d'attente du réseau diminue rapidement, il n'est donc souvent pas stressant d'essayer de rendre les lots aussi volumineux que possible.
Si vous chargez des données en bloc, envisagez sérieusement d'utiliser le COPY API à la place, via le CopyManager de PgJDBC , obtenu via la PgConnection interface. Il vous permet de diffuser des données de type CSV sur le serveur pour un chargement en masse rapide avec très peu d'allers-retours client/serveur. Malheureusement, il est remarquablement sous-documenté - il n'apparaît pas du tout dans les principaux documents PgJDBC, uniquement dans la documentation de l'API
.
