Vous n'êtes pas identifié(e).
Bonjour,
J'ai une requête (qui permet de récupérer le nombre de box changé par chaque technicien lors d'intervention pour une période données ainsi que le nombre totale d'intervention pour la période données pour chaque IPCA) qui est très lourde et donc je souhaiterais l'optimiser.
J'ai trouvé sur internet, un site qui parle de fonctions fenêtrées (http://sqlpro.developpez.com/article/ol … se-window/) et ça à l'air d'être pas mal pour optimiser la requête.
Voici ma requête de base :
SELECT DISTINCT intervention.int_refinst, ((coalesce(change_box_ig,0))+(coalesce(change_box_sav,0)))AS nb_box, (coalesce(nb_inter_sav,0)+coalesce(nb_inter_ig,0))AS nb_inter
FROM intervention LEFT JOIN
(SELECT int_refinst, COUNT(*) AS change_box_ig
FROM intervention JOIN conclusion_ig ON id_ca = conclu_ig_id
WHERE conclu_ig_date BETWEEN '20091214' AND '20091219'
AND conclu_ig_anc_box <>''
GROUP BY int_refinst) as tab_ig ON tab_ig.int_refinst = intervention.int_refinst
LEFT JOIN
(SELECT int_refinst, COUNT(*) AS change_box_sav
FROM intervention JOIN conclusion_sav ON id_ca = conclu_sav_id
WHERE conclu_sav_date BETWEEN '20091214' AND '20091219'
AND conclu_sav_anc_box <>''
GROUP BY int_refinst) as tab_sav ON tab_sav.int_refinst = intervention.int_refinst
LEFT JOIN
(SELECT int_refinst,COUNT(*) AS nb_inter_sav
FROM intervention JOIN conclusion_sav ON id_ca = conclu_sav_id
WHERE conclu_sav_date BETWEEN '20091214' AND '20091219'
GROUP BY int_refinst
HAVING COUNT(*) > 10
) as tab_nb_inter_sav on tab_nb_inter_sav.int_refinst = intervention.int_refinst
LEFT JOIN
(SELECT int_refinst,COUNT(*) AS nb_inter_ig
FROM intervention JOIN conclusion_ig ON id_ca = conclu_ig_id
WHERE conclu_ig_date BETWEEN '20091214' AND '20091219'
GROUP BY int_refinst
HAVING COUNT(*) > 10
) as tab_nb_inter_ig on tab_nb_inter_ig.int_refinst = intervention.int_refinst
WHERE (nb_inter_sav IS NOT NULL OR nb_inter_ig IS NOT NULL)
AND (change_box_ig IS NOT NULL OR change_box_sav IS NOT NULL)Pour essayer... j'ai essayer de réaliser cette requête :
SELECT int_refinst, COUNT(*) OVER(PARTITION BY int_refinst) FROM intervention;Mais j'obtiens l'erreur suivante :
ERROR: syntax error at or near "OVER"
LINE 1: SELECT int_refinst, COUNT(*) OVER(PARTITION BY int_refinst) ...
^
********** Erreur **********
ERROR: syntax error at or near "OVER"
État SQL :42601
Caractère : 30
J'ai deux questions :
1) Quelqu'un as-t'il une idée pour régler mon erreur??
2) Quelqu'un pourrais-t'il m'aider pour re-construire ma requête grâce au fonction fenêtrées??
Merci d'avance
Hors ligne
Bonjour,
Êtes vous bien en PostgreSQL 8.4 ?
Marc.
Hors ligne
Bonjour,
Je suppose que oui car lorsque je vais dans Aide -> A propos je vois écris "versions 1.8.4".
Merci d'avance.
Hors ligne
C'est la version de pgAdmin, pas de PostgreSQL. Si c'est la version livrée avec votre version de PostgreSQL, il y a plus de chance que vous soyez en 8.3. Quel est le résultat de la requête suivante :
SELECT version();Guillaume.
Hors ligne
En fait sous PgAdmin, j'ai 2 serveur :
Le premier qui me permet de faire des tests -> "PostgreSQL 8.2.5 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)"
Le second qui est la partie production -> "PostgreSQL 8.0.2 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)"
Donc je commence sur ma première et ensuite une fois que cela fonctionnera, je migrerait mon projet sous l'autre serveur.
Cordialement.
Hors ligne
Donc je commence sur ma première et ensuite une fois que cela fonctionnera, je migrerait mon projet sous l'autre serveur.
Très mauvaise idée pour deux raisons :
* si vous utilisez des syntaxes ajoutées en 8.1 ou 8.2, elles ne fonctionneront pas en 8.0 ;
* avoir PostgreSQL 8.0 sous Windows, c'est s'assurer d'avoir des bugs... pour infos, ce n'est qu'à partir de la 8.2 que PostgreSQL a une version stable pour Windows (à noter également qu'aucun correctif n'est fourni pour les versions antérieures à la 8.2 sous Windows).
Pour en revenir à votre question, les requêtes de fenêtrage ne sont disponibles qu'à partir de la version 8.4. Le mot clé OVER n'a donc été ajouté qu'à partir de la version 8.4. Donc il est tout à fait logique qu'il vous donne un « syntax error at or near "OVER" » quand vous essayez de l'utiliser sur une 8.2 et sur une 8.0.
Guillaume.
Hors ligne
Ok merci pour la réponse clair et précise.
Je n'est pas le choix, je suis au travail et je ne peux pas changer la version des serveurs de PostgreSQL.
Donc j'ai aucune solution pour optimiser ma requête??
Cordialement
Hors ligne
Je n'ai pas dit ça, j'ai juste dit que ça ne se fera pas en utilisant les requêtes de fenêtrage.
Guillaume.
Hors ligne
Ok mais as-tu une idée pour mieux l'optimiser s'il te plais car je voit pas du tout??
Cordialement.
Hors ligne
Il faudrait fournir un EXPLAIN ANALYZE de la requête pour vous répondre avec plus de sureté.
Guillaume.
Hors ligne
Ok.
Lorsque je vais dans l'onglet "Messages", j'obtiens :
Durée totale d'exécution de la requête :13796 ms.
42 lignes récupérées.
Par contre quand je vais dans l'onglet "Expliquer(Explain)", je n'obtiens aucune information.
Cordialement.
Hors ligne
Parce qu'il faut demander spécifiquement un EXPLAIN ANALYZE.
Guillaume.
Hors ligne
Ok désolé je savait pas.
Donc lorsque je fais un "EXPLAIN ANALYSE" de la requête, voici ce que j'obtiens :
"Unique (cost=173444.01..176724.45 rows=328044 width=39) (actual time=30211.200..30485.622 rows=42 loops=1)"
" -> Sort (cost=173444.01..174264.12 rows=328044 width=39) (actual time=30211.190..30379.267 rows=51648 loops=1)"
" Sort Key: intervention.int_refinst, (COALESCE(tab_ig.change_box_ig, 0::bigint) + COALESCE(tab_sav.change_box_sav, 0::bigint)), (COALESCE(tab_nb_inter_sav.nb_inter_sav, 0::bigint) + COALESCE(tab_nb_inter_ig.nb_inter_ig, 0::bigint))"
" -> Merge Left Join (cost=109091.46..123201.39 rows=328044 width=39) (actual time=24299.792..29755.457 rows=51648 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" Filter: ((tab_nb_inter_sav.nb_inter_sav IS NOT NULL) OR (tab_nb_inter_ig.nb_inter_ig IS NOT NULL))"
" -> Merge Left Join (cost=105512.43..115240.95 rows=328052 width=31) (actual time=23956.297..29057.165 rows=159847 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" -> Merge Left Join (cost=92266.21..96253.83 rows=328052 width=23) (actual time=23528.958..27760.144 rows=159847 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" Filter: ((tab_ig.change_box_ig IS NOT NULL) OR (tab_sav.change_box_sav IS NOT NULL))"
" -> Merge Left Join (cost=87918.23..89655.49 rows=328060 width=15) (actual time=21173.121..23803.847 rows=328176 loops=1)"
" Merge Cond: ("outer"."?column2?" = "inner"."?column3?")"
" -> Sort (cost=86766.80..87586.95 rows=328060 width=7) (actual time=20580.848..21730.980 rows=328176 loops=1)"
" Sort Key: (intervention.int_refinst)::text"
" -> Seq Scan on intervention (cost=0.00..45496.60 rows=328060 width=7) (actual time=0.141..18121.620 rows=328176 loops=1)"
" -> Sort (cost=1151.43..1151.47 rows=16 width=16) (actual time=592.237..661.458 rows=37475 loops=1)"
" Sort Key: (tab_ig.int_refinst)::text"
" -> Subquery Scan tab_ig (cost=1150.75..1151.11 rows=16 width=16) (actual time=591.482..591.866 rows=61 loops=1)"
" -> HashAggregate (cost=1150.75..1150.95 rows=16 width=7) (actual time=591.475..591.616 rows=61 loops=1)"
" -> Nested Loop (cost=11.44..1150.67 rows=16 width=7) (actual time=112.406..591.005 rows=71 loops=1)"
" -> Bitmap Heap Scan on conclusion_ig (cost=11.44..1017.10 rows=16 width=13) (actual time=94.867..447.570 rows=71 loops=1)"
" Recheck Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" Filter: ((conclu_ig_anc_box)::text <> ''::text)"
" -> Bitmap Index Scan on i_conclu_ig_date (cost=0.00..11.44 rows=317 width=0) (actual time=63.304..63.304 rows=1662 loops=1)"
" Index Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.34 rows=1 width=20) (actual time=2.002..2.005 rows=1 loops=71)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_ig.conclu_ig_id)::text)"
" -> Sort (cost=4347.98..4348.57 rows=236 width=16) (actual time=2352.667..2618.697 rows=135117 loops=1)"
" Sort Key: (tab_sav.int_refinst)::text"
" -> Subquery Scan tab_sav (cost=4333.37..4338.68 rows=236 width=16) (actual time=2350.652..2351.831 rows=234 loops=1)"
" -> HashAggregate (cost=4333.37..4336.32 rows=236 width=7) (actual time=2350.644..2351.095 rows=234 loops=1)"
" -> Nested Loop (cost=39.22..4332.19 rows=236 width=7) (actual time=48.143..2349.002 rows=335 loops=1)"
" -> Bitmap Heap Scan on conclusion_sav (cost=39.22..2422.01 rows=236 width=13) (actual time=48.108..1826.013 rows=335 loops=1)"
" Recheck Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" Filter: ((conclu_sav_anc_box)::text <> ''::text)"
" -> Bitmap Index Scan on i_conclu_sav_date (cost=0.00..39.16 rows=1490 width=0) (actual time=42.640..42.640 rows=2537 loops=1)"
" Index Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.08 rows=1 width=20) (actual time=1.545..1.547 rows=1 loops=335)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_sav.conclu_sav_id)::text)"
" -> Sort (cost=13246.22..13248.25 rows=812 width=16) (actual time=427.323..528.795 rows=47831 loops=1)"
" Sort Key: (tab_nb_inter_sav.int_refinst)::text"
" -> Subquery Scan tab_nb_inter_sav (cost=13184.65..13206.98 rows=812 width=16) (actual time=426.784..427.128 rows=44 loops=1)"
" -> HashAggregate (cost=13184.65..13198.86 rows=812 width=7) (actual time=426.776..426.981 rows=44 loops=1)"
" Filter: (count(*) > 10)"
" -> Nested Loop (cost=39.53..13173.47 rows=1490 width=7) (actual time=1.821..419.583 rows=2537 loops=1)"
" -> Bitmap Heap Scan on conclusion_sav (cost=39.53..2418.59 rows=1490 width=13) (actual time=1.797..8.798 rows=2537 loops=1)"
" Recheck Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Bitmap Index Scan on i_conclu_sav_date (cost=0.00..39.16 rows=1490 width=0) (actual time=1.557..1.557 rows=2537 loops=1)"
" Index Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..7.21 rows=1 width=20) (actual time=0.148..0.150 rows=1 loops=2537)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_sav.conclu_sav_id)::text)"
" -> Sort (cost=3579.04..3579.83 rows=317 width=16) (actual time=174.523..199.498 rows=14564 loops=1)"
" Sort Key: (tab_nb_inter_ig.int_refinst)::text"
" -> Subquery Scan tab_nb_inter_ig (cost=3557.15..3565.87 rows=317 width=16) (actual time=174.263..174.387 rows=10 loops=1)"
" -> HashAggregate (cost=3557.15..3562.70 rows=317 width=7) (actual time=174.255..174.349 rows=10 loops=1)"
" Filter: (count(*) > 10)"
" -> Nested Loop (cost=11.52..3554.77 rows=317 width=7) (actual time=1.442..169.784 rows=1662 loops=1)"
" -> Bitmap Heap Scan on conclusion_ig (cost=11.52..1016.38 rows=317 width=13) (actual time=1.153..5.966 rows=1662 loops=1)"
" Recheck Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Bitmap Index Scan on i_conclu_ig_date (cost=0.00..11.44 rows=317 width=0) (actual time=0.955..0.955 rows=1662 loops=1)"
" Index Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.00 rows=1 width=20) (actual time=0.085..0.087 rows=1 loops=1662)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_ig.conclu_ig_id)::text)"
"Total runtime: 30496.614 ms"
En espérant que cette fois-ci ce sera bon 
Merci d'avance.
Hors ligne
Comme l'indique http://explain.depesz.com/s/4tg , ce qui prend le plus de temps, c'est le parcours séquentiel de la table intervention. Tout de suite après, c'est le tri effectué sur ce parcours. Un index sur intervention.int_refinst pourrait définitivement arranger les choses (en terme de performance pure).
Quant à changer la requête, oui, ça pourrait améliorer les choses. J'avoue que j'ai du mal à voir comme ça quelles seraient des modifications sensées.
Guillaume.
Hors ligne
A la lecture de la requête, je trouve cela très curieux, la jointure avec intervention dans chaque sous-requête. J' ai l'impression que les sous-requêtes pourraient toutes fort bien se passer de la jointure avec intervention. Ou alors qu'il y a un truc bizarre dans le schéma.
Est-ce que id_ca identifie la même chose que int_refinst?
Sinon, dites-en un peu plus sur les tables, leur identifiant, les critères de jointure ...
Hors ligne
Bonjour,
Voici la structure de chaque table :
1) Table Intervention :
CREATE TABLE intervention
(
id_ca character varying(9) NOT NULL, -- numéro intervention
int_refinst character varying(4), -- numéro ipca(tech)
int_ig integer DEFAULT 0, - 1 si intervention de type "Installaton Garantie" et 2 pour "SAV"
CONSTRAINT intervention_pkey PRIMARY KEY (id_ca)
)2) Table Conclusion_IG :
CREATE TABLE conclusion_ig
(
conclu_ig_id character varying(9) NOT NULL, -- numéro intervention
conclu_ig_date character varying(8), -- Date de cloture
conclu_ig_anc_box character varying(18), -- Num série ancienne box
conclu_ig_nvl_box character varying(18), -- Num série nouvelle box
CONSTRAINT conclu_ig_pkey PRIMARY KEY (conclu_ig_id)
)3) Table Conclusion_SAV :
CREATE TABLE conclusion_sav
(
conclu_sav_id character varying(9) NOT NULL, -- numéro intervention
conclu_sav_date character varying(8), -- Date de cloture
conclu_sav_anc_box character varying(18), -- Num série ancienne box
conclu_sav_nvl_box character varying(18), -- Num série nouvelle box
CONSTRAINT conclu_sav_pkey PRIMARY KEY (conclu_sav_id)
)J'ai fais la jointure avec la table Intervention dans chacune des sous-requête car il faut que je récupère 'int_refinst' qui se situe dans la table Intervention.
Les 2 première sous-requêtes me permette de récupérer le nombre de box changé lors des interventions pour la période données et les 2 dernière sous-requêtes me permettent de récupérer le nombre d'intervention en tout pour la période données.
Cordialement.
Dernière modification par loicDu28 (21/04/2010 10:19:56)
Hors ligne
La question principale est : qu'est-ce que int_refinst? Dans intervention, y a-t-il plusieurs id_ca pour le même int_refinst ?
Et pourquoi conclusion_ig et intervention ont la même clé?
Hors ligne
int_refinst comme c'est indiqué correspond au numéro du technicien qui à fait cette intervention donc la réponse à "y a-t-il plusieurs id_ca pour le même int_refinst " est oui.
Conclusion_ig est une table qui permet d'obtenir les renseignements lorsque l'intervention est clôturé(la date de la clôture, le changement de box....) par le technicien. Donc le champ conclusion_ig_id correspond à un numéro d'intervention qui est bien entendu un des "id_ca" de la table intervention.
J'espère avoir été clair dans mes réponses.
Merci d'avance.
Hors ligne
Ah oui maintenant je comprends mieux pourquoi vous devez faire la jointure avec intervention à chaque fois.
Avez-vous ajouté l'index sur int_refinst comme conseillé par gleu?
Dernière modification par flo (21/04/2010 15:34:48)
Hors ligne
Oui l'index est créé : i_int_refinst.
Voici la nouvelle requête :
SELECT tab_ig.i_int_refinst, ((coalesce(change_box_ig,0))+(coalesce(change_box_sav,0)))AS nb_box, (coalesce(nb_inter_sav,0)+coalesce(nb_inter_ig,0))AS nb_inter
FROM
(SELECT i_int_refinst, COUNT(*) AS change_box_ig
FROM intervention JOIN conclusion_ig ON id_ca = conclu_ig_id
WHERE conclu_ig_date BETWEEN '20091214' AND '20091219'
AND conclu_ig_anc_box <>''
GROUP BY i_int_refinst) as tab_ig
LEFT JOIN
(SELECT i_int_refinst, COUNT(*) AS change_box_sav
FROM intervention JOIN conclusion_sav ON id_ca = conclu_sav_id
WHERE conclu_sav_date BETWEEN '20091214' AND '20091219'
AND conclu_sav_anc_box <>''
GROUP BY i_int_refinst) as tab_sav
LEFT JOIN
(SELECT i_int_refinst,COUNT(*) AS nb_inter_sav
FROM intervention JOIN conclusion_sav ON id_ca = conclu_sav_id
WHERE conclu_sav_date BETWEEN '20091214' AND '20091219'
GROUP BY i_int_refinst
HAVING COUNT(*) > 10
) as tab_nb_inter_sav
LEFT JOIN
(SELECT i_int_refinst,COUNT(*) AS nb_inter_ig
FROM intervention JOIN conclusion_ig ON id_ca = conclu_ig_id
WHERE conclu_ig_date BETWEEN '20091214' AND '20091219'
GROUP BY i_int_refinst
HAVING COUNT(*) > 10
) as tab_nb_inter_ig
WHERE (nb_inter_sav IS NOT NULL OR nb_inter_ig IS NOT NULL)
AND (change_box_ig IS NOT NULL OR change_box_sav IS NOT NULL)Mais le problème c'est qu'elle ne fonctionne plus, elle m'affiche le message d'erreur suivant :
ERROR: syntax error at or near "WHERE"
LINE 28: WHERE (nb_inter_sav IS NOT NULL OR nb_inter_ig IS NOT NULL)
^********** Erreur **********
ERROR: syntax error at or near "WHERE"
État SQL :42601
Caractère : 1133
Cordialement.
Hors ligne
Ah, désolée j'avais pas lu le détail de la clause Where... Je n'avais pas compris ce qu'elle faisait vraiment.
Il faut bien que vous gardiez intervention dans ce cas. Je ne vois pas comment réécrire cette requête comme ça.
Hors ligne
Ok. Merci quand même pour votre aide.
Par contre, je peux quand même utiliser l'index?? Si oui, comment je doit faire pour l'utiliser dans ma requête?? Car je n'en est jamais utilisé et je voit pas trop.
Cordialement.
Hors ligne
Il faut juste lancer la requête avec un explain analyse pour voir s'il est utilisé.
Dernière modification par flo (21/04/2010 16:42:41)
Hors ligne
Ok.
Voici l'explain analyse :
"Unique (cost=173444.01..176724.45 rows=328044 width=39) (actual time=31535.927..31767.122 rows=42 loops=1)"
" -> Sort (cost=173444.01..174264.12 rows=328044 width=39) (actual time=31535.918..31659.499 rows=51648 loops=1)"
" Sort Key: intervention.int_refinst, (COALESCE(tab_ig.change_box_ig, 0::bigint) + COALESCE(tab_sav.change_box_sav, 0::bigint)), (COALESCE(tab_nb_inter_sav.nb_inter_sav, 0::bigint) + COALESCE(tab_nb_inter_ig.nb_inter_ig, 0::bigint))"
" -> Merge Left Join (cost=109091.46..123201.39 rows=328044 width=39) (actual time=26475.724..31148.898 rows=51648 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" Filter: ((tab_nb_inter_sav.nb_inter_sav IS NOT NULL) OR (tab_nb_inter_ig.nb_inter_ig IS NOT NULL))"
" -> Merge Left Join (cost=105512.43..115240.95 rows=328052 width=31) (actual time=25837.823..30189.183 rows=159847 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" -> Merge Left Join (cost=92266.21..96253.83 rows=328052 width=23) (actual time=25216.883..28833.303 rows=159847 loops=1)"
" Merge Cond: ((intervention.int_refinst)::text = "inner"."?column3?")"
" Filter: ((tab_ig.change_box_ig IS NOT NULL) OR (tab_sav.change_box_sav IS NOT NULL))"
" -> Merge Left Join (cost=87918.23..89655.49 rows=328060 width=15) (actual time=23303.638..25571.859 rows=328176 loops=1)"
" Merge Cond: ("outer"."?column2?" = "inner"."?column3?")"
" -> Sort (cost=86766.80..87586.95 rows=328060 width=7) (actual time=22867.116..23822.785 rows=328176 loops=1)"
" Sort Key: (intervention.int_refinst)::text"
" -> Seq Scan on intervention (cost=0.00..45496.60 rows=328060 width=7) (actual time=0.088..20296.449 rows=328176 loops=1)"
" -> Sort (cost=1151.43..1151.47 rows=16 width=16) (actual time=436.485..501.501 rows=37475 loops=1)"
" Sort Key: (tab_ig.int_refinst)::text"
" -> Subquery Scan tab_ig (cost=1150.75..1151.11 rows=16 width=16) (actual time=435.723..436.103 rows=61 loops=1)"
" -> HashAggregate (cost=1150.75..1150.95 rows=16 width=7) (actual time=435.712..435.840 rows=61 loops=1)"
" -> Nested Loop (cost=11.44..1150.67 rows=16 width=7) (actual time=87.043..435.247 rows=71 loops=1)"
" -> Bitmap Heap Scan on conclusion_ig (cost=11.44..1017.10 rows=16 width=13) (actual time=54.592..277.920 rows=71 loops=1)"
" Recheck Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" Filter: ((conclu_ig_anc_box)::text <> ''::text)"
" -> Bitmap Index Scan on i_conclu_ig_date (cost=0.00..11.44 rows=317 width=0) (actual time=33.812..33.812 rows=1662 loops=1)"
" Index Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.34 rows=1 width=20) (actual time=2.198..2.201 rows=1 loops=71)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_ig.conclu_ig_id)::text)"
" -> Sort (cost=4347.98..4348.57 rows=236 width=16) (actual time=1910.099..2127.287 rows=135117 loops=1)"
" Sort Key: (tab_sav.int_refinst)::text"
" -> Subquery Scan tab_sav (cost=4333.37..4338.68 rows=236 width=16) (actual time=1907.907..1909.190 rows=234 loops=1)"
" -> HashAggregate (cost=4333.37..4336.32 rows=236 width=7) (actual time=1907.880..1908.345 rows=234 loops=1)"
" -> Nested Loop (cost=39.22..4332.19 rows=236 width=7) (actual time=36.562..1906.342 rows=335 loops=1)"
" -> Bitmap Heap Scan on conclusion_sav (cost=39.22..2422.01 rows=236 width=13) (actual time=36.521..1447.509 rows=335 loops=1)"
" Recheck Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" Filter: ((conclu_sav_anc_box)::text <> ''::text)"
" -> Bitmap Index Scan on i_conclu_sav_date (cost=0.00..39.16 rows=1490 width=0) (actual time=29.216..29.216 rows=2537 loops=1)"
" Index Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.08 rows=1 width=20) (actual time=1.354..1.356 rows=1 loops=335)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_sav.conclu_sav_id)::text)"
" -> Sort (cost=13246.22..13248.25 rows=812 width=16) (actual time=620.924..698.282 rows=47831 loops=1)"
" Sort Key: (tab_nb_inter_sav.int_refinst)::text"
" -> Subquery Scan tab_nb_inter_sav (cost=13184.65..13206.98 rows=812 width=16) (actual time=620.415..620.749 rows=44 loops=1)"
" -> HashAggregate (cost=13184.65..13198.86 rows=812 width=7) (actual time=620.407..620.604 rows=44 loops=1)"
" Filter: (count(*) > 10)"
" -> Nested Loop (cost=39.53..13173.47 rows=1490 width=7) (actual time=1.796..613.332 rows=2537 loops=1)"
" -> Bitmap Heap Scan on conclusion_sav (cost=39.53..2418.59 rows=1490 width=13) (actual time=1.763..8.966 rows=2537 loops=1)"
" Recheck Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Bitmap Index Scan on i_conclu_sav_date (cost=0.00..39.16 rows=1490 width=0) (actual time=1.531..1.531 rows=2537 loops=1)"
" Index Cond: (((conclu_sav_date)::text >= '20091214'::text) AND ((conclu_sav_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..7.21 rows=1 width=20) (actual time=0.225..0.227 rows=1 loops=2537)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_sav.conclu_sav_id)::text)"
" -> Sort (cost=3579.04..3579.83 rows=317 width=16) (actual time=469.721..494.556 rows=14564 loops=1)"
" Sort Key: (tab_nb_inter_ig.int_refinst)::text"
" -> Subquery Scan tab_nb_inter_ig (cost=3557.15..3565.87 rows=317 width=16) (actual time=469.385..469.538 rows=10 loops=1)"
" -> HashAggregate (cost=3557.15..3562.70 rows=317 width=7) (actual time=469.377..469.497 rows=10 loops=1)"
" Filter: (count(*) > 10)"
" -> Nested Loop (cost=11.52..3554.77 rows=317 width=7) (actual time=1.203..464.529 rows=1662 loops=1)"
" -> Bitmap Heap Scan on conclusion_ig (cost=11.52..1016.38 rows=317 width=13) (actual time=1.166..6.200 rows=1662 loops=1)"
" Recheck Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Bitmap Index Scan on i_conclu_ig_date (cost=0.00..11.44 rows=317 width=0) (actual time=0.983..0.983 rows=1662 loops=1)"
" Index Cond: (((conclu_ig_date)::text >= '20091214'::text) AND ((conclu_ig_date)::text <= '20091219'::text))"
" -> Index Scan using intervention_pkey on intervention (cost=0.00..8.00 rows=1 width=20) (actual time=0.263..0.265 rows=1 loops=1662)"
" Index Cond: ((intervention.id_ca)::text = (conclusion_ig.conclu_ig_id)::text)"
"Total runtime: 31792.560 ms"
J'ai l'impression qu'il passe jamais dans l'index 'i_int_refinst' (cette index existait déjà à la base, je m'en suit aperçut tout à l'heure.
Voici le code de sa création :
CREATE INDEX i_int_refinst
ON intervention
USING btree
(int_refinst);Cordialement
Hors ligne
Avez-vous exécuté un ANALYZE après la création de l'index ? parce que là, il ne l'utilise pas du tout.
Guillaume.
Hors ligne