Konkrete Werte und der Query Plan Cache


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 des PREPARE 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 Funktion setPrepareThreshold 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., mittels prepared-statement-cache-size in der data-source Konfiguration). Dadurch verliert der Entwickler womöglich die Kontrolle über die PreparedStatement 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.

Über den Autor

Photo of Markus Winand
Markus Winand stimmt Entwickler auf SQL-Performance ein. Er hat das Buch SQL Performance Explained veröffentlicht und bietet inhouse Schulungen sowie Tuning-Leistungen auf http://winand.at/ an.