Phoenix Genma Ken
Loptimisation consistant à ne PAS faire quelque chose est la plus efficace. Ici, nous allons nous intéresser aux jointures.
Guillaume Lelarge écrit dans son livre "PostgreSQL, architecture et notions avancées" que le planner (optimiseur) est capable depuis la version 9.0 déviter certaines jointures inutiles.
Démonstration avec PostgreSQL 10 beta :
Nous réalisons une jointure externe gauche entre lancers et geants en utilisant la colonne idg. La colonne idg constitue la clé primaire de geants donc il existe 0 ou 1 idg dans la table geants pour chaque idg dans la table lancers. Si javais ajouté une clé étrangère entre geants et lancers ce serait 1 mais peu importe. Ce qui est important ici, cest que ça ne puisse pas être 2 ou plus. En effet, que ce soit 0 ou 1, chaque ligne de lancers respectant la clause de filtrage nous donne une ligne de résultats. La clause de jointure ne modifie donc pas le nombre de lignes qui seraient retournées en interrogeant seulement la table lancers.
Nous ne demandons que des informations de la table lancers au niveau de la clause de projection. Ici, il sagit de la colonne lancers.idg.
Le planner fait la même conclusion que nous : la jointure avec geants ne modifie pas les lignes retournées par la requête. Autant donc ne pas réaliser cette jointure.
Alors cest magique et nous navons plus besoin de réfléchir ? Hmmm nous allons tout de même creuser.
Que fait la 1ère requête ? Nous cherchons lidentifiant des géants et leur date de naissance, quils aient lancé ou non puisquil sagit dune jointure externe gauche entre geants et lancers.
Nous éliminons les doublons donc, même si un géant berserk a lancé plusieurs fois, nous nobtiendrons quune seule fois son idg dans les résultats.
Nous ne demandons que des informations de la table geants au niveau de la clause de projection, les colonnes geants.idg et geants.dtn.
La jointure avec lancers est superflue mais elle est nest pas indolore car PostgreSQL la réalise effectivement au contraire de ce que nous avions observé précédemment.
En fait, ce que nous cherchions ici à obtenir, cétait la liste des berserks. La 2ème requête donne cette liste aussi bien que la 1ère mais elle est plus simple et moins coûteuse puisquelle ne comporte pas la jointure avec lancers.
Conclusion
PostgreSQL peut, dans certains cas, ne pas réaliser une jointure que son planner juge inutile. Cependant cela ne dispense pas de réfléchir sur les requêtes. Le plus sûr moyen de ne pas exécuter quelque chose dinutile reste encore de ne pas le demander lors de lécriture du code SQL, quel que soit le SGBD. Les informations fournies dans cet article sont égalalement valables avec Oracle Database 11.2.0.4 par exemple.