Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 29/03/2010 18:28:02
- David
- Membre
Pb comportement analyseur 8.4 avec table partitionnées
Bonjour à tous.
J'ai qqs soucis de performances avec une table partitionnée.
J'avais, à l'époque de la 8.3.3, positionné le paramètre constraint_exlusion=on pour forcer l'analyseur.
Par contre j'ai qqs doutes sur ce qui est décrit dans la doc 8.4 par rapport à ce que l'explain montre:
"La valeur par défaut (et donc recommandée) de constraint_exclusion n'est ni on ni off, mais un état intermédiaire appelé partition, qui fait que la technique est appliquée seulement aux requêtes qui semblent fonctionner avec des tables partitionnées.")
Voici ma config par défaut donc:
bdcp => show constraint_exclusion ;
constraint_exclusion
----------------------
partition
(1 row)
bdcp=> explain
delete * from mn_v1 where num_poste=31069001;
QUERY PLAN
----------------------------------------------------------------------------------------------
Append (cost=2.27..373978.79 rows=737150 width=6)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep01 on mn_v1_dep01 mn_v1 (cost=0.00..4.62 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep02 on mn_v1_dep02 mn_v1 (cost=0.00..4.53 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep03 on mn_v1_dep03 mn_v1 (cost=0.00..4.82 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep04 on mn_v1_dep04 mn_v1 (cost=0.00..4.60 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep05 on mn_v1_dep05 mn_v1 (cost=0.00..4.73 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep06 on mn_v1_dep06 mn_v1 (cost=0.00..5.30 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep07 on mn_v1_dep07 mn_v1 (cost=0.00..5.19 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep08 on mn_v1_dep08 mn_v1 (cost=0.00..4.49 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep09 on mn_v1_dep09 mn_v1 (cost=0.00..4.46 rows=1 width=6)
Index Cond: (num_poste = 31069001)
..........
..........
ETC ETC jusqu'à 100 partitions.
Par contre si je force constraint_exclusion à la main ...
bdcp=> SET constraint_exclusion = on;
SET
bdcp=> show constraint_exclusion
;
constraint_exclusion
----------------------
on
(1 row)
bdcp=> explain
delete from mn_v1 where num_poste=31069001;
QUERY PLAN
-------------------------------------------------------------------------------------------
Append (cost=2.27..40136.12 rows=422484 width=6)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Bitmap Heap Scan on mn_v1_dep31 mn_v1 (cost=6546.70..40130.72 rows=422482 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on pk_mn_v1_dep31 (cost=0.00..6441.08 rows=422482 width=0)
Index Cond: (num_poste = 31069001)
(9 rows)
Beaucoup mieux, on se limite à la partition cible.
Ai-je mal interprété la documentation ? Ai-je qq part une surcharge du paramètre "constraint_exlusion" ? Un comportement modififié par des mauvaises stats ?
Merci par avance.
David.
Hors ligne
#2 29/03/2010 19:07:02
- Marc Cousin
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
Avant d'aller plus loin, est-ce que le comportement est le même avec la même requête en select qu'en delete ?
SELECT * from mn_v1 where num_poste=31069001;
Marc.
Hors ligne
#3 30/03/2010 08:10:57
- David
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
Effectivement, cela parait correct pour le SELECT:
bdcp=> show constraint_exclusion;
constraint_exclusion
----------------------
partition
(1 row)
bdcp=> explain
select * from mn_v1 where num_poste=31069001;
QUERY PLAN
--------------------------------------------------------------------------------------------------
Result (cost=2.27..40157.05 rows=422678 width=41)
-> Append (cost=2.27..40157.05 rows=422678 width=41)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=148)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Bitmap Heap Scan on mn_v1_dep31 mn_v1 (cost=6552.20..40151.65 rows=422676 width=41)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on pk_mn_v1_dep31 (cost=0.00..6446.53 rows=422676 width=0)
Index Cond: (num_poste = 31069001)
(10 rows)
Hors ligne
#4 30/03/2010 09:19:26
- Marc Cousin
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
Cela semble être un bug ou une limitation. Je vais la remonter aux développeurs de ce pas. En attendant, passez le constraint exclusion à on, je crois que vous n'avez pas trop le choix 
En tout cas merci pour l'analyse du problème.
Marc.
Hors ligne
#5 30/03/2010 09:39:16
- David
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
OK message reçu Marc.
Merci pour le support.
Hors ligne
#6 31/03/2010 12:20:23
- Marc Cousin
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
Salut,
Le correctif a été appliqué et sera disponible dans la 8.4.3 et la 9.0.
Marc.
Hors ligne
#7 31/03/2010 12:32:53
- gleu
- Administrateur
Re : Pb comportement analyseur 8.4 avec table partitionnées
Euh, juste un correctif au message de Marc. Tom Lane a appliqué le correctif dans la branche 8.4 et dans la branche 9.0 (celle qui est en cours de développement). Par contre, la première version 8.4 qui en disposera est la 8.4.4 (la 8.4.3 étant déjà sortie).
Guillaume.
Hors ligne
#8 31/03/2010 18:47:36
- Marc Cousin
- Membre
Re : Pb comportement analyseur 8.4 avec table partitionnées
Oups, pas taper, trop rapide à rédiger
Marc.
Hors ligne