Det ser ud til, at dette er en kombination af en Spring "bug" og en driver "bug".
Spring forsøger at bestemme datatypen for en kolonne hver gang setValue() Hedder. Det gør det ved at kalde PreparedStatementMetaData.getParameterMetaData()
Dette medfører tilsyneladende, at der sendes en "forbered"-erklæring til databasen, som i sig selv er ret hurtig (aldrig mere end 1 ms på min bærbare computer), men som det kaldes for hver kolonne for hver række opsummerer dette en masse tid (det kaldes for hver ikke-nul værdi, hvilket resulterer i ca. 23.000 opkald)
Til en vis grad er dette mere en Spring-fejl end en driver-fejl, fordi det ikke giver mening at cache parameteren metadata (i hvert fald efter min mening). MySQL JDBC-driveren understøtter ikke getParameterMetaData() og Spring ved dette, så denne "fejl" dukker ikke op med MySQL, fordi spring aldrig kalder den metode.
Jeg er ikke sikker på, om Postgres' JDBC-driveradfærd kan klassificeres som en fejl, men det ville bestemt være rart, hvis driveren cachelagde de metadata efter det første opkald.
Spring kan overbevises om ikke at få erklæringens metadata gennem egenskaben spring.jdbc.getParameterType.ignore
Så ved at sætte:
System.setProperty("spring.jdbc.getParameterType.ignore", "true");
før linjen:
LetsGo letsGo = new LetsGo();
denne adfærd er deaktiveret.
Egenskaben skal indstilles før Fjeder er initialiseret.
Når jeg gør det med dit eksempelprojekt, kører indsatsen på 500 ms på min bærbare computer.
Rediger
Efter at have set kommentaren vedrørende brugen af Postgres-NG-driveren gravede jeg i kilderne til den "officielle" driver og NG-driveren, og NG-driveren cacher parametermetadata efter det første kald, hvorimod den officielle driver ikke forklarer, hvorfor det er så meget hurtigere at bruge NG-driveren (uden at deaktivere opkaldet om foråret)