IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration PostgreSQL Discussion :

idx_scan + seq_scan


Sujet :

Administration PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Homme Profil pro
    dba
    Inscrit en
    Décembre 2016
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : dba
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2016
    Messages : 119
    Par défaut idx_scan + seq_scan
    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

  2. #2
    Membre Expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Billets dans le blog
    8
    Par défaut
    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
    @+

  3. #3
    Membre confirmé
    Homme Profil pro
    dba
    Inscrit en
    Décembre 2016
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : dba
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2016
    Messages : 119
    Par défaut
    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 ?

  4. #4
    ced
    ced est déconnecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    Avril 2002
    Messages
    6 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Avril 2002
    Messages : 6 059
    Par défaut
    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.
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre confirmé
    Homme Profil pro
    dba
    Inscrit en
    Décembre 2016
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : dba
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2016
    Messages : 119
    Par défaut
    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

  7. #7
    Membre Expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Billets dans le blog
    8
    Par défaut
    Salut
    Citation Envoyé par SQLpro Voir le message
    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 +
    Il manque la phrase magique: "changer de SGBD"
    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.
    @+

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo