Frühling JDBCTemplate + Postgres, ist die gleiche Anfrage sehr langsam

Question

Ich habe diese SQL-Anfrage:

SELECT num.top, num.top/1.0E7 as value, num.grille_id, 13 as resultat_id FROM (
SELECT SUM(c.top + a.top2 * 900) as top, a.grille_id FROM exe_resultat a 
INNER JOIN exe_resultat_2 c ON c.resultat_id=11 AND c.grille_id = a.grille_id 
WHERE a.resultat_id =13 GROUP BY a.grille_id 
UNION ALL 
SELECT a.top2 * 900 as top, a.grille_id FROM exe_resultat a 
LEFT JOIN exe_resultat_2 c ON c. resultat_id=11 AND c.grille_id = a.grille_id 
WHERE a.resultat_id =13 AND c.grille_id IS NULL 
UNION ALL 
SELECT c.top, c.grille_id FROM exe_resultat_2 c 
LEFT JOIN exe_resultat a ON a. resultat_id=13 AND a.grille_id = c.grille_id 
WHERE c.resultat_id =11 AND a.grille_id IS NULL) num ORDER BY num.grille_id; 

Es gibt etwa 15.000 Zeilen in weniger als 1 Sekunde auf PGAdmin. Wenn ich es in meiner Java-Anwendung mit Spring JDBC ausführe, dauert es manchmal weniger als 1 Sekunde, aber manchmal dauert es viel länger (> 1 Minute). Es besteht eine Wahrscheinlichkeit von 50%, dass die Anforderung länger als 1 Minute anhält. Wenn es passiert, kann ich auf der PGAdmin Server Status Registerkarte sehen, dass die Anfrage noch ausgeführt wird.

Es ist nicht durch eine andere Transaktion blockiert. Ich habe versucht, fetchSize von JDBC zu erhöhen. Ich habe versucht, die Anfrage mit LIMIT und OFFSET zu paginieren, um jedes Mal nur 1000 Zeilen zurückzugeben. Ich habe es mit oder ohne Vorbereitung versucht. Ich habe auch versucht, die Anfrage in einem JUnit-Test lopping 100 Mal auszuführen und es war in Ordnung.

Es tritt nur auf der Anwendung, die eine Batch-Anwendung mit mehreren Thread (Executor) sequenziell in einer bestimmten Reihenfolge ausgeführt wird Operation in der Datenbank ausgeführt wird. Ich vermute, dass diese Multithread-Umgebung in die Ursache des Problems involviert ist.

Answer 1

Ich schließe das Problem endlich. Es war der Plan der Anfrage, der zwischen der ersten und der zweiten Anfrage nicht derselbe war. Die Durchführung der Vakuumanalyse löst das Problem. Es war also ein reines PostgreSQL-Problem.