11.8. Examiner l'usage des index

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�s sur un syst�me en production. On v�rifie l'utilisation d'un index pour une requ�te particuli�re avec la commande EXPLAIN. Son utilisation dans notre cas est expliqu�e dans Section 13.1. Il est aussi possible de rassembler des statistiques globales sur l'utilisation des index sur un serveur en cours de fonctionnement, comme d�crit dans Section 23.2.

Il est difficile de donner une proc�dure g�n�rale pour d�terminer quels index doivent �tre cr��s. Plusieurs cas typiques ont �t� cit�s dans les exemples pr�c�dents. Une bonne dose d'exp�rimentation sera n�cessaire dans de nombreux cas. Le reste de cette section donne quelques pistes.

• La premi�re chose � faire est de lancer ANALYZE. Cette commande collecte les informations sur la distribution des valeurs dans la table. Cette information est n�cessaire pour essayer de deviner le nombre lignes retourn�es par une requ�te. L'optimiseur de requ�tes en a besoin pour donner des co�ts r�alistes aux diff�rents plans de requ�tes possibles. En l'absence de statistiques r�elles, le syst�me utilise quelques valeurs par d�faut, qui ont toutes les chances d'�tre inadapt�es. Examiner l'utilisation des index par une application sans avoir lanc� ANALYZE pr�alablement est du coup une cause perdue.

• Utilisez des donn�es r�elles pour l'exp�rimentation. Utiliser des donn�es de test pour mettre en place des index vous permettra de trouver les index dont vous avez besoin pour vos donn�es de test, mais c'est tout.

  Il est particuli�rement n�faste d'utiliser un jeu de donn�es constitu� en r�duisant proportionnellement des donn�es r�elles. Alors qu'une requ�te s�lectionnant 1000 lignes parmi 100000 pourrait utiliser un index, il est peu probable qu'une requ�te s�lectionnant 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�cution qui puisse aller plus vite que la lecture d'une seule page.

  Soyez aussi vigilant en cr�ant des donn�es de test, ce qui est souvent in�vitable quand l'application n'est pas encore en production. Les valeurs qui sont tr�s similaires, compl�tement al�atoire, ou ins�r�es d�j� tri�es peuvent modifier la distribution des donn�es et fausser les statistiques.

• Quand les index ne sont pas utilis�s, il peut �tre utile pour les tests de forcer leur utilisation. Certains param�tres d'ex�cution du serveur peuvent interdire certains types de plans (d�crits dans Section 16.4). Par exemple, en interdisant les lectures s�quentielles de tables enable_seqscan) et les jointures � boucles imbriqu�es (enable_nestloop), qui sont les deux plans les plus basiques, on forcera le syst�me � utiliser un plan diff�rent. Si le syst�me continue n�anmoins � choisir une lecture s�quentielle ou une jointure � boucles imbriqu�es, alors il y a probablement un probl�me plus fondamental qui emp�che l'utilisation de l'index, par exemple que la condition ne correspond pas � l'index. (Les sections pr�c�dentes expliquent quelles sortes de requ�tes peuvent utiliser quelles sortes d'index.)

• Si l'index est effectivement utilis� en for�ant son utilisation, alors il y a deux possibilit�s: Soit le syst�me a raison et l'utilisation de l'index est effectivement inappropri�e, soit les co�ts estim�s des plans de requ�tes ne refl�tent pas la r�alit�. Il faut alors comparer la dur�e de la requ�te avec et sans index. La commande EXPLAIN ANALYZE peut �tre utile pour cela.

• S'il appara�t que les estimations de co�ts sont fausses, il y a de nouveau deux possibilit�s. Le co�t total est calcul� � partir du co�t par ligne de chaque nœud du plan, multipli� par l'estimation de s�lectivit� du nœud de plan. Le co�t des nœuds de plan peut �tre optimis� avec des param�tres d'ex�cution (d�crits dans Section 16.4). Une estimation de s�lectivit� inadapt�e est due � des statistiques insuffisantes. Il est peut �tre possible de les am�liorer en optimisant les param�tres de collecte de statistiques. Voir ALTER TABLE).

  Si vous n'arrivez pas � ajuster les co�ts pour qu'ils repr�sentent mieux la r�alit�, alors vous devrez forcer l'utilisation de l'index explicitement. Vous pouvez aussi, si vous le voulez, contacter les d�veloppeurs de PostgreSQL afin qu'ils examinent le probl�me.