PgJDBC ma pewne ograniczenia dotyczące partii:
-
Wszystkie wartości żądań i wszystkie wyniki muszą być gromadzone w pamięci. Obejmuje to wyniki dużych obiektów typu blob/clob. Tak więc wolna pamięć jest głównym czynnikiem ograniczającym wielkość partii.
-
Do PgJDBC 9.4 (jeszcze nie wydany) , partie zwracające wygenerowane klucze zawsze wykonują ruch w obie strony dla każdego wpisu , więc nie są lepsze niż wykonywanie pojedynczych instrukcji.
-
Nawet w wersji 9.4 partie, które zwracają wygenerowane klucze, oferują korzyści tylko wtedy, gdy wygenerowane wartości mają ograniczony rozmiar. Pojedynczy
text,bytealub nieograniczonyvarcharpole w żądanym wyniku zmusi kierowcę do wykonania podróży w obie strony dla każdego wykonania .
Zaletą grupowania jest zmniejszenie liczby podróży w obie strony w sieci. Więc nie ma sensu, jeśli baza danych jest lokalna na serwerze aplikacji. Wraz ze wzrostem wielkości partii maleje zwrot, ponieważ całkowity czas oczekiwania w sieci szybko się zmniejsza, więc często nie jest to stresujące próbowanie tworzenia partii tak dużych, jak to możliwe.
Jeśli ładujesz dane zbiorczo, poważnie rozważ użycie COPY Zamiast tego API, za pośrednictwem CopyManager PgJDBC , uzyskany przez PgConnection interfejs. Umożliwia przesyłanie strumieniowe danych podobnych do CSV na serwer w celu szybkiego ładowania zbiorczego przy bardzo niewielu podróżach w obie strony klient/serwer. Niestety, jest on wyjątkowo słabo udokumentowany – w ogóle nie pojawia się w głównych dokumentach PgJDBC, tylko w dokumentacji interfejsu API
.
