PREPARE |
Préparer |
PostgreSQL |
Syntaxe
PREPARE name [ ( data_type [, ...] ) ] AS statement
|
Paramètres
Nom |
Description |
name |
Ce paramètre permet d'indiquer le nom arbitraire donné à cette instruction préparée particulière. Il doit être unique au sein d'une même session et est ensuite utilisé pour exécuter ou désallouer une instruction préalablement préparée. |
data_type |
Ce paramètre permet d'indiquer le type de données d'un paramètre de l'instruction préparée. Si le type de données d'un paramètre particulier n'est pas spécifié ou est spécifié comme inconnu, il sera déduit du contexte dans lequel le paramètre est utilisé pour la première fois. Pour faire référence aux paramètres dans l'instruction préparée elle-même, utilisez $1, $2,... |
statement |
Ce paramètre permet d'indiquer toute instruction SELECT, INSERT, UPDATE, DELETE ou VALUES. |
Description
Cette instruction permet de préparer un instruction d'exécution.
Remarques
- L'instruction PREPARE crée une instruction préparée. Une instruction préparée est un objet côté serveur pouvant être utilisé pour optimiser les performances. Lorsque l'instruction PREPARE
est exécutée, l'instruction spécifiée est analysée, analysée et réécrite. Lorsqu'une commande EXECUTE est ensuite émise, l'instruction préparée est planifiée et exécutée. Cette division du travail
évite les travaux répétitifs d'analyse syntaxique, tout en permettant au plan d'exécution de dépendre des valeurs de paramètres spécifiques fournies.
- Les instructions préparées peuvent prendre des paramètres : des valeurs qui sont substituées dans l'instruction lors de son exécution. Lors de la création de l'instruction préparée, reportez-vous
aux paramètres par position, en utilisant $1, $2,... Une liste correspondante de types de données de paramètres peut éventuellement être spécifiée. Lorsque le type de données d'un paramètre n'est pas
spécifié ou est déclaré comme inconnu, le type est déduit du contexte dans lequel le paramètre est utilisé pour la première fois (si possible). Lors de l'exécution de l'instruction, spécifiez les valeurs
réelles de ces paramètres dans l'instruction EXECUTE.
- Les instructions préparées ne durent que pour la durée de la session de base de données en cours. Lorsque la session se termine, l'instruction préparée est oubliée, elle doit donc être recréée avant
d'être réutilisée. Cela signifie également qu'une seule instruction préparée ne peut pas être utilisée par plusieurs clients de base de données simultanés ; cependant, chaque client peut créer sa
propre déclaration préparée à utiliser. Les instructions préparées peuvent être nettoyées manuellement à l'aide de la commande DEALLOCATE.
- Les instructions préparées présentent potentiellement le plus grand avantage en termes de performances lorsqu'une seule session est utilisée pour exécuter un grand nombre d'instructions similaires.
La différence de performances sera particulièrement importante si les instructions sont complexes à planifier ou à réécrire, par exemple, si la requête implique une jointure de plusieurs tables ou
nécessite l'application de plusieurs règles. Si l'instruction est relativement simple à planifier et à réécrire, mais relativement coûteuse à exécuter, l'avantage en termes de performances des
instructions préparées sera moins visible.
- Les instructions préparées peuvent utiliser des plans génériques plutôt qu'une replanification avec chaque ensemble de valeurs EXECUTE fournies. Cela se produit immédiatement pour les
instructions préparées sans paramètres ; sinon, il se produit uniquement après que cinq exécutions ou plus produisent des plans dont le coût moyen estimé (y compris les frais généraux de planification)
est plus élevé que l'estimation des coûts du plan générique. Une fois qu'un plan générique est choisi, il est utilisé pour la durée de vie restante de l'instruction préparée. L'utilisation de valeurs
EXECUTE étant rares dans les colonnes avec de nombreux doublons peut générer des plans personnalisés tellement moins chers que le plan générique, même après avoir ajouté une surcharge de
planification, que le plan générique peut ne jamais être utilisé.
- Un plan générique suppose que chaque valeur fournie à EXECUTE est l'une des valeurs distinctes de la colonne et que les valeurs de colonne sont uniformément distribuées. Par exemple, si
les statistiques enregistrent trois valeurs de colonne distinctes, un plan générique suppose qu'une comparaison d'égalité de colonne correspondra à 33 % des lignes traitées. Les statistiques de
colonne permettent également aux plans génériques de calculer avec précision la sélectivité de colonnes uniques. Les comparaisons sur des colonnes distribuées de manière non uniforme et la spécification
de valeurs inexistantes affectent le coût moyen du plan, et donc si et quand un plan générique est choisi.
- Pour examiner le plan de requête utilisé par PostgreSQL pour une instruction préparée, utilisez EXPLAIN, par exemple EXPLAIN EXECUTE. Si un plan
générique est utilisé, il contiendra les symboles de paramètre $n, tandis qu'un plan personnalisé aura les valeurs de paramètre fournies lui étant substituées. Les estimations de ligne dans
le plan générique reflètent la sélectivité calculée pour les paramètres.
- Bien que le point principal d'une instruction préparée soit d'éviter l'analyse et la planification répétées de l'instruction, PostgreSQL forcera la réanalyse et la replanification de
l'instruction avant de l'utiliser chaque fois que les objets de base de données utilisés dans l'instruction ont subi des modifications de définition (DDL) depuis la précédente utilisation
de l'instruction préparée. De plus, si la valeur de search_path change d'une utilisation à l'autre, l'instruction sera ré-analysée à l'aide du nouveau search_path. (Ce dernier
comportement est nouveau depuis PostgreSQL 9.3.) Ces règles utilisent une instruction préparée sémantiquement presque équivalente à la soumission répétée du même texte de requête, mais
avec un avantage en termes de performances si aucune définition d'objet n'est modifiée, en particulier si le le meilleur plan reste le même pour toutes les utilisations. Un exemple de cas où
l'équivalence sémantique n'est pas parfaite est que si l'instruction fait référence à une table par un nom non qualifié, puis qu'une nouvelle table du même nom est créée dans un schéma
apparaissant plus tôt dans search_path, aucun re-l'analyse se produira car aucun objet utilisé dans l'instruction n'a changé. Cependant, si un autre changement force une nouvelle
analyse, la nouvelle table sera référencée dans les utilisations suivantes.
Dernière mise à jour : Jeudi, le 14 Octobre 2021