Envoyé par
SQLpro
Attention, dans les deux cas il s'agit de lectures séquentielle. Pour l'une dans la table, pour l'autre dans l'index.
Contrairement à ce qui vous a été dit, et aussi surprenant que cela puisse paraître, une lecture d'index n'est pas toujours meilleurs qu'une lecture de table.... !
En effet, les index sont des données triées alors que les tables ne le sont pas. En cas de modification d'une valeur, il est très probable que l'index se fragmentera, sauf si vous avez affaire à un excellent DBA maitrisant parfaitement la maintenance des index (ce qui est rare vu les outils plus que faiblard dont dispose PG...) car la modification va désorganiser le tri, de la même manière que rajouter un nouveau mot dans un dico relève de l'impossibilité de bien faire, sauf à refaire l'édition dudit dico, et se traduira donc par une page "verrue" ajouté entre deux pages..... Or une table, par nature n'étant pas triée, la modification d'une ligne n'a pas d'influence sur la situation de la ligne dans l'espace de stockage de la table.
Ainsi donc et de manière très naturelle, à l'usage des bases de données, les mises à jour (INSERT, UPDATE, DELETE) fragmentent de manière considérable les index les rendant 2 ou 3 fois plus gros, voire bien plus, que lors de leur construction.... Et c'est ce pourquoi il existe une nécessaire maintenance des index.
De ce fait, l'index peut se révéler plus gros que la table et le scan d'index peut devenir plus gourmand que le scan de table...
Mais le problème est que, dans PG, l'optimiseur ne sait pas mesurer la fragmentation de l'index et finalement opter pour le scan de table si ce dernier s'avère plus efficace parce que moindre en volumétrie !
A +