Comment est-il possible que Hash Index ne soit pas plus rapide que Btree pour les recherches d'égalité?
Pour chaque version de Postgres prenant en charge hachage l'indexation, un avertissement ou une note indique que les index de hachage sont "similaires ou index "ou" pas meilleur "que btree index, au moins jusqu'à la version 8.3. De la documentation:
Remarque: En raison de l'utilité limitée des index de hachage, un index B-tree doit généralement être préféré à un index de hachage. Nous n'avons pas de preuves suffisantes que les indices de hachage sont en fait plus rapides que les arbres B, même pour les comparaisons =. De plus, les index de hachage nécessitent des verrous plus grossiers; voir Section 9.7.
Version 7.3 (et jusqu'à 8.2) :
Remarque: Les tests ont montré que les index de hachage de PostgreSQL sont similaires ou plus lents que les index B-tree, et la taille de l'index et le temps de construction des index de hachage sont bien pires . Les indices de hachage souffrent également de mauvaises performances dans des conditions de concurrence élevée. Pour ces raisons, l'utilisation de l'index de hachage est déconseillée.
Remarque: Les tests ont montré que les index de hachage de PostgreSQL ne fonctionnent pas mieux que les index B-tree, et la taille de l'index et le temps de construction des index de hachage sont bien pires. De plus, les opérations d'index de hachage ne sont pas actuellement enregistrées en WAL, il peut donc être nécessaire de reconstruire les index de hachage avec REINDEX après un crash de la base de données. Pour ces raisons, l'utilisation de l'indice de hachage est actuellement déconseillée.
Dans ce fil de la version 8. , ils affirment n'avoir jamais trouvé de cas où les index de hachage étaient en fait plus rapides que btree.
Même dans la version 9.2, le gain de performances pour autre chose que l'écriture de l'index réel n'était presque rien selon ce billet de blog (14 mars 2016):
Hash Indexes on Postgres par André Barbosa.
Ma question est comment est-ce possible?
Par définition, les index Hash sont une opération O(1), où un btree est une opération O(log n). Alors, comment est-il possible qu'une recherche O(1) soit plus lente que (ou même similaire à) la recherche de la bonne branche, puis la recherche du bon enregistrement?
Je veux savoir ce que la théorie de l'indexation pourrait JAMAIS en faire!
Les index Btree basés sur disque sont vraiment O (log N), mais cela est à peu près sans importance pour les matrices de disques qui correspondent à ce système solaire. En raison de la mise en cache, ils sont principalement O(1) avec une très grande constante plus O ((log N) -1) avec une petite constante. Formellement, c'est la même chose que O ( log N), car les constantes n'ont pas d'importance en grande notation O. Mais elles importent en réalité.
Une grande partie du ralentissement des recherches d'index de hachage provient de la nécessité de se protéger contre la corruption ou les blocages provoqués par le redimensionnement de la table de hachage en même temps que les recherches. Jusqu'à des versions récentes (chaque version que vous mentionnez est comiquement obsolète), ce besoin a conduit à des constantes encore plus élevées et à une concurrence plutôt médiocre. Beaucoup plus d'heures de travail ont été consacrées à l'optimisation de la simultanéité BTree que la simultanéité de hachage.
La recherche de hachage est théoriquement une opération O(1) lorsque le hachage de clé est directement mappé à l'emplacement physique de l'enregistrement cible. La façon dont cela fonctionne dans Postgres, si je comprends bien, est un peu plus compliquée: le hachage de clé est mappé sur un compartiment qui contient le OID que vous recherchez. Un compartiment peut potentiellement comprendre plus d'une page, que vous devez analyser séquentiellement jusqu'à ce que vous trouviez votre clé particulière (hachage). C'est pourquoi elle apparaît plus lentement que prévu.
La méthode d'accès à l'index de hachage fichier README dans le dépôt de code source a tous les détails.