Vocalização Ultrassônica

Bien que les index de PostgreSQL n’aient pas besoin de maintenance ni d’optimisation, il est important de s’assurer que les index sont effectivement utilis´es sur un syst`eme en production.

On v´erifie l’utilisation d’un index pour une requˆete particuli`ere avec la commandeEXPLAIN. Son utilisation dans notre cas est expliqu´ee dans la section 17.1. Il est aussi possible de rassembler des statistiques globales sur l’utilisation des index sur un serveur en cours de fonctionnement, comme cela est d´ecrit dans ls section 12.2.

Il est difficile de donner une proc´edure g´en´erale pour d´eterminer quels index doivent ˆetre cr´e´es.

Plusieurs cas typiques sont g´en´eralement abord´es lors des initiations au langage SQL. Une bonne dose d’exp´erimentation sera n´ecessaire dans de nombreux cas. Le reste de cette section donne quelques pistes.

La premi`ere chose `a faire est de lancerANALYZE. Cette commande collecte les informations sur la distribution des valeurs dans la table. Cette information est n´ecessaire pour essayer de deviner le nombre lignes retourn´ees par une requˆete. L’optimiseur de requˆetes en a besoin pour donner des coˆuts r´ealistes aux diff´erents plans de requˆetes possibles. En l’absence de statistiques r´eelles, le syst`eme utilise quelques valeurs par d´efaut, qui ont toutes les chances d’ˆetre inadapt´ees. Examiner l’utilisation des index par une application sans avoir lanc´e ANALYZEpr´ealablement est une cause perdue.

Utilisez des donn´ees r´eelles pour l’exp´erimentation. Utiliser des donn´ees de test pour mettre en place des index vous permettra de trouver les index dont vous avez besoin pour vos donn´ees de test, mais c’est tout. Il est particuli`erement n´efaste d’utiliser un jeu de donn´ees constitu´e en r´eduisant proportionnellement des donn´ees r´eelles. Alors qu’une requˆete s´electionnant 1000 lignes parmi 100000 pourrait utiliser un index, il est peu probable qu’une requˆete s´electionnant 1 ligne dans une table de 100 lignes le fasse, parce que les 100 lignes tiennent probablement dans une seule page sur le disque, et qu’il n’y a aucun plan d’ex´ecution qui puisse aller plus vite que la lecture d’une seule page.

Soyez aussi vigilant en cr´eant des donn´ees de test, ce qui est souvent in´evitable quand l’appli-cation n’est pas encore en production. Les valeurs qui sont tr`es similaires, compl`etement al´eatoire, ou ins´er´ees d´ej`a tri´ees peuvent modifier la distribution des donn´ees et fausser les statistiques.

Quand les index ne sont pas utilis´es, il peut ˆetre utile pour les tests de forcer leur utilisation.

Certains param`etres d’ex´ecution du serveur peuvent interdire certains types de plans (d´ecrits dans ls section 4.4). Par exemple, en interdisant les lectures s´equentielles de tablesenable seqscan) et les jointures `a boucles imbriqu´ees (enable nestloop), qui sont les deux plans les plus basiques, on forcera le syst`eme `a utiliser un plan diff´erent. Si le syst`eme continue n´eanmoins `a choisir une lecture s´equentielle ou une jointure `a boucles imbriqu´ees, alors il y a probablement un probl`eme plus fondamental qui empˆeche l’utilisation de l’index, par exemple que la condition ne correspond pas `a l’index.

Si l’index est effectivement utilis´e en for¸cant son utilisation, alors il y a deux possibilit´es : Soit le syst`eme a raison et l’utilisation de l’index est effectivement inappropri´ee, soit les coˆuts estim´es des plans de requˆetes ne refl`etent pas la r´ealit´e. Il faut alors comparer la dur´ee de la requˆete avec et sans index. La commandeEXPLAIN ANALYZEpeut ˆetre utile pour cela.

S’il apparaˆıt que les estimations de coˆuts sont fausses, il y a de nouveau deux possibilit´es. Le coˆut total est calcul´e `a partir du coˆut par ligne de chaque nœud du plan, multipli´e par l’estimation

de s´electivit´e du nœud de plan. Le coˆut des nœuds de plan peut ˆetre optimis´e avec des param`etres d’ex´ecution (d´ecrits dans la section 4.4). Une estimation de s´electivit´e inadapt´ee est due `a des statistiques insuffisantes. Il est peut ˆetre possible de les am´eliorer en optimisant les param`etres de collecte de statistiques. Voir ALTER TABLE).

Si vous n’arrivez pas `a ajuster les coˆuts pour qu’ils repr´esentent mieux la r´ealit´e, alors vous devrez forcer l’utilisation de l’index explicitement. Vous pouvez aussi, si vous le voulez, contacter les d´eveloppeurs de PostgreSQL afin qu’ils examinent le probl`eme.