Vous n'êtes pas identifié(e).
Pages : 1
les schémas sont identiques.
je cherche des informations de répartition de données "différentes" mais je ne trouve pas grand chose manuellement.
pas de répartitions tres originale pour ce département.
(je suis en train de creuser l'analyse de ce côté.)
Vous pensez à un probleme de stats?
Limit (cost=131.26..344091.59 rows=100 width=543) (actual time=14245.027..401557.521 rows=100 loops=1)
-> Nested Loop (cost=131.26..1461962.69 rows=425 width=543) (actual time=14245.025..401557.437 rows=100 loops=1)
-> Merge Join (cost=131.26..1459351.57 rows=425 width=375) (actual time=14240.453..401104.198 rows=100 loops=1)
Merge Cond: (((c.ident)::text = v.ident) AND ((c.dossier)::text = (v.dossier)::text))
-> Index Scan using controle_tech_pkey on controle_tech c (cost=0.00..773993.48 rows=483132 width=76) (actual time=1002.566..236317.019 rows=1612 loops=1)
Index Cond: (type = 3)
Filter: ((d_dif IS NULL) AND ((departement)::text = '66'::text) AND (status = 'OK'::status_type))
-> Index Scan using voiture_pkey on voiture v (cost=0.00..678791.53 rows=1972731 width=299) (actual time=0.050..164449.243 rows=210255 loops=1)
Filter: (date(d_loc) < '2013-06-07'::date)
-> Index Scan using loueur_pkey on loueur l (cost=0.00..6.13 rows=1 width=168) (actual time=2.628..4.523 rows=1 loops=100)
Index Cond: ((ident)::text = (c.ident)::text)
Total runtime: 401557.804 ms
EXECUTION PROBLEME :
Limit (cost=131.20..343826.72 rows=100 width=543)
-> Nested Loop (cost=131.20..1460837.17 rows=425 width=543)
-> Merge Join (cost=131.20..1458226.05 rows=425 width=375)
Merge Cond: (((c.ident)::text = v.ident) AND ((c.dossier)::text = (v.dossier)::text))
-> Index Scan using controle_tech_pkey on controle_tech c (cost=0.00..773165.47 rows=483132 width=76)
Index Cond: (type = 3)
Filter: ((d_dif IS NULL) AND ((departement)::text = '66'::text) AND (status = 'OK'::status_type))
-> Index Scan using voiture_pkey on voiture v (cost=0.00..678491.52 rows=1972731 width=299)
Filter: (date(d_loc) < '2013-06-07'::date)
-> Index Scan using loueur_pkey on loueur l (cost=0.00..6.13 rows=1 width=168)
Index Cond: ((ident)::text = (c.ident)::text)
EXECUTION OK :
Limit (cost=0.00..162608.77 rows=100 width=637)
-> Nested Loop (cost=0.00..11930605.13 rows=7337 width=637)
-> Nested Loop (cost=0.00..11893133.11 rows=7337 width=478)
-> Seq Scan on controle_tech c (cost=0.00..651662.00 rows=2843501 width=76)
Filter: ((d_dif IS NULL) AND ((departement)::text = '66'::text) AND (type = 3) AND (status = 'OK'::status_type))
-> Index Scan using voiture_pkey on voiture v(cost=0.00..3.94 rows=1 width=402)
Index Cond: ((ident = (c.ident)::text) AND ((dossier)::text = (c.dossier)::text))
Filter: (date(d_loc) < '2013-06-07'::date)
-> Index Scan using loueur_pkey on loueur l(cost=0.00..5.09 rows=1 width=159)
Index Cond: ((ident)::text = (c.ident)::text)
Bonjour,
je rencontre un problème de dégradation de performances pour une requête qui est assez subtile :
- Le problème concerne une requête sur 3 tables. par exemple loueur (750.000 lignes), voiture (6.000.000 lignes), contrôle technique(9.500.000 lignes)
- La requête ressemble à ça :
select c.*,v.*,l.* from controle_tech c, voiture v, loueur l
where c.ident = v.ident and c.dossier = v.dossier and c.ident = l.ident
and c.departement = '66' and c.type = 3 and date(v.d_loc) < '2013-06-07' and c.status = 'OK' and c.d_dif IS NULL
limit 100
- J'ai 10 instances du même schéma de base (répartition des données géographiquement par "régions"), chacune regroupe quelques départements français
- la requête est lancée pour chaque département indépendamment.
PROBLEME :
cette requête fonctionne correctement sur tous les départements, sauf 1 !
pour tous les départements (sur différentes instances de base) le planificateur fait un Seq Scan sur controle_tech (et une nested loop après)
pour ce département (66 dans l'exemple) le planificateur fait un Index Scan sur la pk controle_tech (et un merge join après)
et là!..... c'est la catastrophe (45mn pour 100 lignes!)
BONNE EXECUTION :
controle_tech ==> nested loop ==> nested loop ==> limit
/ /
voiture_pk / loueur_pk /
MAUVAISE EXECUTION :
controle_tech_pk ==> merge join ==> nested loop ==> limit
/ /
voiture_pk / loueur_pk /
INFOS :
un vaccum semble résoudre le problème temporairement (quelques jours)
version pgsql : 9.1.6
QUESTION :
quelqu'un connait une méthode qui permettrait d'analyser pourquoi le planificateur fait ce (mauvais) choix alors que ça fonctionne correctement dans les autres cas?
En quoi le vaccum corrige le probleme? (un ANALYSE seul ne change rien)
Merci d'avance
Pages : 1
