Par défaut, une fonction est juste une « boîte noire » dont la base de données connait très peu le comportement. De ce fait, il peut arriver que les requêtes utilisant la fonction se trouvent exécutées beaucoup moins efficacement qu'elles ne pourraient. Il est possible de fournir une connaissance supplémentaire qui aide le planificateur à optimiser les appels de fonctions.
Quelques indications basiques peuvent être données via les annotations
déclaratives présentes dans la commande CREATE FUNCTION
.
La plus importante de celles-ci est la
catégorie de volatilité (IMMUTABLE
, STABLE
,
ou VOLATILE
) ; on doit toujours être très soucieux
de la spécifier correctement lorsqu'on définit une fonction.
La propriété de sûreté face au parallélisme (PARALLEL
UNSAFE
, PARALLEL RESTRICTED
, ou
PARALLEL SAFE
) doit également être spécifiée
pour espérer utiliser la fonction dans des requêtes parallélisées.
Il peut aussi être utile de spécifier le coût estimé de l'exécution
de la fonction, et le nombre de lignes qu'une fonction
renvoyant un ensemble d'enregistrements est estimée renvoyer.
Toutefois, la manière déclarative de spécifier ces deux informations
ne permet seulement que de donner une valeur constante, ce qui est
souvent inadéquat.
Il est aussi possible de rattacher une fonction de support de planification à une fonction appelable en SQL (appelée fonction cible), et ainsi de fournir sur la fonction cible une connaissance qui serait trop complexe à être représentée déclarativement. Les fonctions de support de planification doivent être écrites en C (alors que leurs fonctions cibles peuvent ne pas l'être), ce qui en fait une fonctionnalité avancée que relativement peu de personnes utiliseront.
Une fonction de support de planification doit avoir la signature SQL
supportfn(internal) returns internal
Elle est rattachée à sa fonction cible en spécifiant la clause
SUPPORT
dans la création de la fonction cible.
Les détails de l'API des fonctions de support de planification
se trouvent dans le fichier
src/include/nodes/supportnodes.h
dans le code
source de PostgreSQL. Ici, on ne fournit
qu'une vue d'ensemble de ce que les fonctions de support de planification
peuvent faire.
L'ensemble des demandes possibles adressables à une fonction de support
est extensible, si bien que d'autres choses seront possibles dans
des versions ultérieures.
Certains appels de fonctions peuvent être simplifiés lors de la
planification en se basant sur les propriétés spécifiques de la fonction.
Par exemple, int4mul(n, 1)
pourrait être simplifié par
n
. Ce type de transformation peut être exécuté
par une fonction de support de planification, en lui faisant implémenter
le type de demande SupportRequestSimplify
.
La fonction de support va être appelée pour chaque instance de la
fonction cible trouvée dans l'arbre d'analyse de la requête.
Si elle trouve qu'un appel particulier peut être simplifié en
une autre forme, elle est capable de construire et renvoyer
un arbre d'analyse représentant cette expression. Cela fonctionnera
automatiquement pour les opérateurs basés sur cette fonction,
également -- dans l'exemple juste ci-dessus, n * 1
serait aussi simplifié en n
.
(Mais notez que c'est juste un exemple ; cette optimisation particulière
n'est pas réellement mise en oeuvre par PostgreSQL.)
Nous ne garantissons pas que PostgreSQL n'appelera
jamais la fonction cible dans les cas que la fonction de support pourrait
simplifier. Assurez-vous d'une équivalence rigoureuse entre l'expression
simplifiée et l'exécution réelle de la fonction cible.
Pour les fonctions cible qui renvoient un booléen, il est souvent utile
d'estimer la fraction des lignes qui vont être sélectionnées par une clause
WHERE
utilisant cette fonction. Ceci est réalisable avec
une fonction de support qui implémente le type de demande
SupportRequestSelectivity
.
Si le temps d'exécution d'une fonction cible est très dépendant
de ses entrées, il peut être utile de fournir un coût d'exécution
non constant pour celle-ci.
Ceci est réalisable avec une fonction de support implémentant
le type de demande SupportRequestCost
.
Pour les fonctions cibles qui renvoient des ensembles de lignes,
il est souvent utile de fournir une estimation non constante du
nombre de lignes renvoyées.
Ceci est réalisable avec une fonction de support implémentant
le type de demande SupportRequestRows
.
Pour les fonctions cibles qui renvoient un booléen, il est envisageable
de convertir un appel de fonction au niveau d'un WHERE
vers une ou
plusieurs clauses d'un opérateur indexable. Ces clauses peuvent être
exactement équivalentes à la condition de la fonction, ou bien elle peuvent
être plus faibles (c'est-à-dire qu'elles peuvent accepter certaines
valeurs que la condition via la fonction n'accepte pas).
Dans ce dernier cas, la condition d'index est dite
avec perte; elle peut toujours être utilisée
pour un parcours d'index, mais la fonction devra être appelée pour chaque
ligne renvoyée par l'index pour vérifier qu'elle satisfait la condition
WHERE
.
Pour créer de telles conditions, la fonction de support doit implémenter
le type de demande SupportRequestIndexCondition
.