Het lijkt erop dat dit een combinatie is van een Spring "bug" en een driver "bug".
Spring probeert het gegevenstype van een kolom elke keer te bepalen setValue() wordt genoemd. Het doet dit door PreparedStatementMetaData.getParameterMetaData() aan te roepen
Dit zorgt er blijkbaar voor dat er een "prepare"-statement naar de database wordt gestuurd, wat op zichzelf vrij snel is (nooit meer dan 1ms op mijn laptop) maar zoals het voor elke kolom wordt genoemd voor elke rij komt dit neer op veel tijd (het wordt aangeroepen voor elke niet-null-waarde, wat resulteert in ongeveer 23.000 aanroepen)
Tot op zekere hoogte is dit meer een Spring-bug dan een driver-bug, omdat het niet echt zinvol is om de parametermetagegevens in de cache op te slaan (althans naar mijn mening). Het MySQL JDBC-stuurprogramma ondersteunt getParameterMetaData() niet en Spring weet dit en dus verschijnt deze "bug" niet met MySQL omdat spring die methode nooit aanroept.
Ik weet niet zeker of het gedrag van het JDBC-stuurprogramma van Postgres als een bug kan worden geclassificeerd, maar het zou mooi zijn als het stuurprogramma die metagegevens na de eerste oproep in de cache zou opslaan.
Spring kan worden overtuigd om de metagegevens van de verklaring niet te verkrijgen via de eigenschap spring.jdbc.getParameterType.ignore
Dus door te zetten:
System.setProperty("spring.jdbc.getParameterType.ignore", "true");
voor de regel:
LetsGo letsGo = new LetsGo();
dit gedrag is uitgeschakeld.
De eigenschap moet voor . zijn ingesteld De lente wordt geïnitialiseerd.
Als ik dat doe met je voorbeeldproject, draait de insert in 500 ms op mijn laptop.
Bewerken
Na het zien van de opmerking over het gebruik van de Postgres-NG-driver heb ik me verdiept in de bronnen van de "officiële" driver en de NG-driver, en de NG-driver cachet de parametermetagegevens na de eerste oproep, terwijl de officiële driver dat niet doet legt uit waarom het gebruik van de NG-driver zoveel sneller is (zonder de oproep in het voorjaar uit te schakelen)