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

Requêtes PostgreSQL Discussion :

Non utilisation de l'index


Sujet :

Requêtes PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2004
    Messages : 319
    Par défaut Non utilisation de l'index
    Bonjour

    voici ma requete
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    SELECT a.id_serv,a.id_app,sum(a.obj_sauve),sum(a.vol_sauve),
    sum(a.nb_sauve),sum(a.err_sauve),sum(a.obj_rest),
    sum(a.vol_rest),sum(a.nb_rest),sum(a.err_rest)
    ,a.id_dom_1,a.id_dom_2,a.id_dom_3,
    a.id_dom_4,a.id_dom_5,a.id_dom_6,
    a.id_dom_7,a.id_dom_8
    FROM tab_stat_app_jour a,domaines b
    WHERE a.date>=to_date('01/03/2010', 'DD/MM/YYYY')
    AND a.date<to_date('01/03/2010', 'DD/MM/YYYY')+ '1 month'::interval
    AND b.domaine='mon_domaine'
    And (b.id_dom=a.id_dom_1
    or b.id_dom=a.id_dom_2
    or b.id_dom=a.id_dom_3
    or b.id_dom=a.id_dom_4
    or b.id_dom=a.id_dom_5
    or b.id_dom=a.id_dom_6
    or b.id_dom=a.id_dom_7
    or b.id_dom=a.id_dom_8)
    group by a.id_serv,a.id_app,
    a.id_dom_1,a.id_dom_2,a.id_dom_3,
    a.id_dom_4,a.id_dom_5,a.id_dom_6,
    a.id_dom_7,a.id_dom_8;
    J'ai essayé de mettre un index sur le champ date ou sur le champ id_serv.
    Dans les deux cas, l'index n'est pas utilisé. Hors comme je commence à avoir pas mal de donnée, la durée du traitement evolue considerablement.
    Je passe de 14mn à presque 30 mn maintenant
    Que faire .....

  2. #2
    Membre régulier
    Inscrit en
    Janvier 2010
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : Janvier 2010
    Messages : 10
    Par défaut
    Bonjour,

    Il y a peut-être des index plus judicieux à trouver.

    Peux-tu poster le EXPLAIN de ta table ?

    Cordialement,

  3. #3
    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
    Vous avez un OR dans votre cluse WHERE portant sur la même table que votre colonne DATE. Dès lors aucun index ne peut être utilisé car le prédicat n'est pas "Sargable".

    Revoyez votre modèle de donnée pour expurger cet immonde groupe de OR, car vu la répétition des colonnes (id_dom_1, id_dom_2, id_dom_3...) vous violez la première forme normale.

    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/ * * * * *

  4. #4
    Membre éclairé
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2004
    Messages : 319
    Par défaut
    Merci SQLpro pour ta réponse.

    Par contre, je vais avoir du mal à modifier mon modèle de donnée.
    Explication:
    J'ai un serveur qui est rattaché à une application et cette application est rattaché au minimum deux domaines maximum huit.
    Pour eviter la redondance des données, que j'ai créé cette table.
    Car, un serveur peut evolué dans le temps. Ce qui veut dire changer d'application.

    Par contre, je suis preneur sur toute piste me permettant de faire evoluer mon modéle de donnée.
    J'espère avoir été suffisament claire.

  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
    Eh bien justement, créé une table des dommaines de rattachement et fais une jointure avec. Du coup tu pourras mettre un index efficace.

    Toute table T comptant N colonne (C1, C2, C3...) et comportant une clef (sur les colonnes (Cx, Cy, Cz...), peut être remplacée par deux tables T1 et T2 plus petites qui partagent la même clef : T1 (Cx, Cy, Cz, C1) T2 (Cx, Cy, Cz, C2, C3, C4)

    S'il existe des colonnes de groupe répétitifs, alors il faut ajouter dans la seconde table une colonne supplémentaire participant à la clef pour pallier à la répétition :
    T1 (Cx, Cy, Cz, C1) T2 (Cx, Cy, Cz, Cn, C2, C3, C4)

    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 éclairé
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2004
    Messages : 319
    Par défaut
    Bonjour,

    voici l'avancé de mes reflexions
    Creations de deux tables en lieu et place de celle existante
    La 1ere
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    mabase=# \d tab_stat_app_jour_dom1
    Table "public.tab_stat_app_jour_dom1"
      Column   |  Type   | Modifiers
    -----------+---------+-----------
     id_serv   | integer |
     date      | date    |
     obj_sauve | integer |
     vol_sauve | integer |
     nb_sauve  | integer |
     err_sauve | integer |
     obj_rest  | integer |
     vol_rest  | integer |
     nb_rest   | integer |
     err_rest  | integer |
     id_app    | integer |
     id_dom_1  | integer |
    et la deuxieme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    mabase=# \d tab_stat_app_jour_dom2
    Table "public.tab_stat_app_jour_dom2"
      Column  |  Type   | Modifiers
    ----------+---------+-----------
     id_serv  | integer |
     date     | date    |
     id_app   | integer |
     id_dom_2 | integer |
     id_dom_3 | integer |
     id_dom_4 | integer |
     id_dom_5 | integer |
     id_dom_6 | integer |
     id_dom_7 | integer |
     id_dom_8 | integer |
    ma nouvelle requete est
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    SELECT a.id_serv,a.id_app,sum(a.obj_sauve),sum(a.vol_sauve),
    sum(a.nb_sauve),sum(a.err_sauve),sum(a.obj_rest),
    sum(a.vol_rest),sum(a.nb_rest),sum(a.err_rest)
    ,a.id_dom_1
    FROM tab_stat_app_jour_dom1 a,domaines b
    WHERE a.date>=to_date('01/03/2010', 'DD/MM/YYYY')
    AND a.date<to_date('01/03/2010', 'DD/MM/YYYY')+ '1 month'::interval
    AND b.domaine='mon_domaine'
    And b.id_dom=a.id_dom_1
    group by a.id_serv
    j'ai ensuite essayé de créer un index sur le champ date ou le champ id_serv sur la table tab_stat_app_jour_dom1 mais l'index n'est toujours pas utilisé.
    A mon avis j'ai loupé quelque chose

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [11gR2] Non utilisation d'un index (optimiseur)
    Par punkoff dans le forum SQL
    Réponses: 29
    Dernier message: 22/10/2013, 15h34
  2. Non-utilisation d'index !
    Par CaptainT dans le forum Administration
    Réponses: 9
    Dernier message: 08/01/2009, 18h49
  3. indexation non utilisée pour chaînes de caractères
    Par ctobini dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 11/02/2008, 09h43
  4. [Optimisation] index non utilisé et using temporary
    Par jp_rennes dans le forum Requêtes
    Réponses: 6
    Dernier message: 23/10/2006, 10h05
  5. [TUNING] pb non utilisation de l'index
    Par ruthene dans le forum Oracle
    Réponses: 10
    Dernier message: 13/04/2006, 17h02

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