Version imprimable
Bonjour à tous,
Qui a une idée sur la différence entre idx_scan + seq_scan ?
Sur Internet, je viens de trouver ces deux définitions :
- seq_scan:Nombre de parcours séquentiels initiés sur cette table
- idx_scan:Nombre de parcours d'index initiés sur cette table
Et quelle est l'opération la moins coûteuse entre ces deux opérations ?
Merci
Salut
seq_scan:=parcourir le livre pour trouver une expression donnée
idx_scan:=parcourir l'indexe du livre pour trouver la page de l'expression et ensuite aller à la page.
A vous de faire une conclusion;)
@+
Donc si je comprends bien, l'opération idx_scan doit être plus performante que l'opération seq_scan.
Une deuxième question svp : dans quel cas l'optimiseur dans PostgreSQL fait le choix de faire du seq_scan au lieu de idx_scan ?
Oui, le parcours via un index est plus performant que le parcours séquentiel.
Pour répondre à votre deuxième question, il peut y avoir plusieurs raisons pour que l'optimiseur choisisse plutôt le parcours séquentiel. J'en vois quelques-unes :
- il n'y a pas d'index utilisable pour exécuter la requête formulée ;
- la table contient peu de lignes ;
- une condition porte sur une colonne qui a une valeur unique ou très peu de valeurs différentes ;
- etc.
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 +
et si l'optimiseur a choisit par exemple de faire un idx_scan et je modifie par exemple ma requête en ajoutant un clause "where" j'aurai t'il une
opération de Type seek au lieu du scan ou le PG a que l'opération scan
A partir du moment ou les critères de filtrage et/ou de jointure changent, l'optimiseur reconsidère la stratégie
La liste des colonnes utilisées peut également changer la stratégie dans la mesure ou un index qui était couvrant ne l'est plus ou inversement
Salut
Il manque la phrase magique: "changer de SGBD"Citation:
Envoyé par SQLpro
Et au fil des messages on se fait une vision réelle de la personne.
Je vous cite...Heureusement que les autres ne perdent pas leurs temps à vous écouter et se contentent d'avancer techniquement.
@+