PostgreSQL hat keinen globalen Cache für Ausführungspläne. Stattdessen gibt es einen optionalen Cache für prepared Statements. Das bedeutet, dass der Entwickler die Wahl hat, den Ausführungsplan für ein prepared Statement zu cachen, oder nicht. Der Cache wird auf jeden Fall verworfen, wenn das prepared Statement geschlossen wird.
Die folgenden Beispiele zeigen, wie man diese Funktionalität benutzt:
- C
Die native C API stellt die Funktion
PQexecParams
zur Verfügung. Damit kann man schon während desPREPARE
Schrittes konkrete Werte angeben, die bei der Erstellung des Ausführungsplanes berücksichtigt werden.- Java
Beim PostgreSQL JDBC Trieiber kann man server-seitiges
PEPARE
mit der proprietären FunktionsetPrepareThreshold
von PGStatement und PGConnection einstellen.Beachte, dass der Wert standardmäßig fünf ist. Das bewirkt, dass die ersten vier Ausführungen die konkreten Werte benutzen, die weiteren Ausführungen dann nicht mehr. Das ganze geht wieder von vorne los, wenn ein neues
PreparedStatement
Objekt verwendet wird.Warnung
Einige Ausführungsumgebungen (Application Server) verwenden einen
PreparedStatement
Cache (z.B., mittelsprepared-statement-cache-size
in der data-source Konfiguration). Dadurch verliert der Entwickler womöglich die Kontrolle über diePreparedStatement
Instanzen, sodass das Limit jederzeit zuschlagen könnte.- Ruby
Ruby’s PGconn.exec erwartet die konkreten Werte als optionales Argument. Falls vorhanden, werden diese Werte beim Erstellen des Ausführungsplanes benutzt. Jeff Davis hat ein Beispiel dazu gemacht.