Wygląda na to, że jest to połączenie "błędu" Springa i "błędu" sterownika.
Spring próbuje określić typ danych kolumny za każdym razem, gdy setValue() jest nazywany. Robi to, wywołując PreparedStatementMetaData.getParameterMetaData()
To najwyraźniej powoduje wysłanie do bazy danych „przygotowania”, co samo w sobie jest dość szybkie (nigdy więcej niż 1 ms na moim laptopie), ale jak to się nazywa dla każdej kolumny dla każdego wiersza sumuje się to do dużej ilości czasu (wywoływane dla każdej wartości niezerowej, co daje około 23 000 wywołań)
W pewnym stopniu jest to bardziej błąd Springa niż błąd sterownika, ponieważ nie buforowanie metadanych parametrów nie ma sensu (przynajmniej moim zdaniem). Sterownik MySQL JDBC nie obsługuje metody getParameterMetaData() Spring o tym wie, więc ten „błąd” nie pojawia się w MySQL, ponieważ spring nigdy nie wywołuje tej metody.
Nie jestem pewien, czy zachowanie sterownika JDBC Postgresa można sklasyfikować jako błąd, ale na pewno byłoby miło, gdyby sterownik buforował te metadane po pierwszym wywołaniu.
Spring można przekonać, aby nie uzyskiwać metadanych instrukcji za pomocą właściwości spring.jdbc.getParameterType.ignore
Więc umieszczając:
System.setProperty("spring.jdbc.getParameterType.ignore", "true");
przed linia:
LetsGo letsGo = new LetsGo();
to zachowanie jest wyłączone.
Właściwość należy ustawić przed Wiosna jest inicjowana.
Kiedy robię to z twoim przykładowym projektem, wstawka działa na moim laptopie w ciągu 500 ms.
Edytuj
Po zapoznaniu się z komentarzem dotyczącym użycia sterownika Postgres-NG sięgnąłem do źródeł „oficjalnego” sterownika i sterownika NG, a sterownik NG buforuje metadane parametrów po pierwszym wywołaniu, podczas gdy oficjalny sterownik nie wyjaśnia, dlaczego korzystanie ze sterownika NG jest o wiele szybsze (bez wyłączania połączenia wiosną)
