Det verkar som att detta är en kombination av en fjäder-"bugg" och en förar-"bugg".
Spring försöker bestämma datatypen för en kolumn varje gång setValue() kallas. Den gör detta genom att anropa PreparedStatementMetaData.getParameterMetaData()
Detta gör tydligen att en "prepare"-sats skickas till databasen som i sig är ganska snabb (aldrig mer än 1ms på min bärbara dator) men som det kallas för varje kolumn för varje rad summerar detta till mycket tid (det anropas för varje icke-nullvärde vilket resulterar i ca 23 000 anrop)
Till viss del är detta mer en Spring-bugg än en drivrutinsbugg, eftersom att inte cachelagra parametermetadata är inte riktigt vettigt (åtminstone enligt min mening). MySQL JDBC-drivrutinen stöder inte getParameterMetaData() och Spring vet detta och så denna "bugg" dyker inte upp med MySQL eftersom spring aldrig kallar den metoden.
Jag är inte säker på om Postgres JDBC-drivrutinbeteende kan klassificeras som en bugg, men det skulle säkert vara trevligt om föraren cachelagrade den metadata efter det första samtalet.
Spring kan övertygas om att inte hämta satsens metadata genom egenskapen spring.jdbc.getParameterType.ignore
Så genom att sätta:
System.setProperty("spring.jdbc.getParameterType.ignore", "true");
före raden:
LetsGo letsGo = new LetsGo();
detta beteende är inaktiverat.
Egenskapen måste ställas in före Våren är initierad.
När jag gör det med ditt exempelprojekt körs insatsen på 500 ms på min bärbara dator.
Redigera
Efter att ha sett kommentaren angående användningen av Postgres-NG-drivrutinen grävde jag i källorna till den "officiella" drivrutinen och NG-drivrutinen, och NG-drivrutinen cachelagrade parametermetadata efter det första anropet medan den officiella drivrutinen inte förklarar varför det går så mycket snabbare att använda NG-drivrutinen (utan att inaktivera samtalet på våren)