Les haches ne sont pas près dabattre Yggdrasil
Dans cette première partie, nous avons découvert que les index HASH étaient à leur avantage, conformément à la théorie, en remplacement des B-Tree pour indexer les chaînes de caractères et réaliser ensuite des tests dégalité. Cette efficacité conduit le planner à être plus optimiste dans son estimation du coût dun Index Scan via un index Hash que via un B-Tree.
Cet optimisme nest-il pas excessif dans certains cas ? Pour le savoir, nous allons reprendre la table GEANTS mais cette fois avec 10 millions de lignes, créer une table temporaire CHAOS avec 1 millions de lignes de GEANTS sélectionnées aléatoirement. Nous allons ensuite tenter une jointure entre les 2 tables, dabord sans index, puis avec un index HASH sur la colonne DEVISE de GEANTS, DEVISE étant la colonne utilisée pour la jointure. Les mêmes tests sont ensuite réalisés en remplaçant CHAOS par ORDO, une table comprenant aussi 1 million de lignes de GEANTS, mais sans tri aléatoire.
Démonstration avec PostgreSQL 10 beta :
Le serveur est assez équilibé et dispose de 32Go de RAM, cest à dire une quantité suffisante pour mettre les données en cache. De toute façon, même sans inciter le planner à privilégier le passage par les index, il choisit les boucles imbriquées lorsque lindex HASH est présent.
Le coût global des boucles imbriquées impliquant 1 million dINDEX SCAN est estimé comme largement inférieur à celui de la jointure de type HASH JOIN. Et pourtant les faits démentent cet optimisme : 25s et même 36s avec les boucles imbriquées dans un cas très défavorable contre 16s voire moins de 15s en augmentant la mémoire de travail sans lindex.
Certes, si le but était de renvoyer les premiers résultats le plus rapidement possible, alors le coût de 0 contre 38647 est assez réaliste. Mais si le but était dobtenir tout le jeu de résultats de la manière la plus efficace alors cest raté : le coût de 270 000 contre 1 400 000 est largement sous-évalué.
Conclusion
Tester légalité entre chaînes de caractères peut être rendu plus performant gràce à lindexation HASH.
Il faut cependant veiller aux excès doptimisme du planner en ce qui concerne les Index Scan lorsque les index utilisent la méthode HASH, notamment si vos clés sont des chaînes de caractères et que vous réalisez des jointures sur de larges volumes de données. A confirmer bien sûr sur VOTRE environnement. Comme dhabitude, les résultats peuvent en effet grandement varier en fonction des ressources à disposition.