Re: planer en delire !!!

Jean-Christophe ARNU (JX) wrote:

>Le Wed, 27 Aug 2003 16:03:51 +0200
>Daniel <daniel(at)12move(dot)be> me disait que :
>
>
>
>>salut
>>comme je l'avais deja dit bonne idee de faire une liste en francais
>>
>>je commence tout de suite avec une question de _planer_ et postgresql
>>7.3.3 (debian)
>>j'ai une table matable(serie serial,a int,b, int c int,d int,e int,f
>>int)(>5000000 de lignes), index unique sur (serie) + index unique sur
>>(a,b,c,d,e,f) et index sur (a)
>>lorsque je fais explain select * from matable where a=12; le planer ne
>>veut pas utiliser les index pourtant il y a un index actif pour la
>>colonne a, par contre si je fais explain select * from matable where
>>a=12 and b=14; la sa marche il utilise l'index (a,b,c,d,e,f).avant
>>j'utilisais postgres 7.2.1 et cela fanctionnais tres bien.
>>je sais qu'il y a une discution sur ce sujet sur la liste anglo.
>>(pourtant sans solution).
>>j'ai du forcer l'utilisation des index dans le fichier de config pour
>>avoir le resultat voulu
>>si qlq'un a une autre solution
>>
>>
>
> Salut Daniel,
>
> En fait, d'aprés ce que j'ai cru comprendre, le planner utilise les
>statistiques des tables et index afin de choisir la manière dont il va
>construire sa requête. Dans le cas d'une table où il y a peu de lignes dans ta
>table, le planner choisira à coup sûr (si tu as un nombre de colonnes
>limitées) de taper directement dans la table plutôt que de charger l'index,
>puis la table. Lorsque tu modifies le fichier de configuration de PG afin de
>l'obliger à utiliser les index, tu restreint le planner dans son efficacité
>(AMHA) en l'obligeant à faire deux parcours (Index+table).
> Si ta table est pleine de lignes (bien peuplée donc), et que ton
>explain ne change pas il y a fort à parier que les stats ne soient pas à jour.
>Il te sera donc nécessaire de faire un VACUUM ANALYZE sur la table ou un
>REINDEX sur les index qui t'intéressent ou carrément sur la table.
>
> Voilà, c'est ce que j'ai pu observer lors de mes diverses expériences
>avec PG et que certaines docs piochées de droite et de gauche, on confirmé.
>
> A+
>
>
>
>
>
salut Jean-Christophe

j'ai fais vacuum analyze et aussi reindex avant de me tourner vers la liste
(de plus suite a un explain il est concluant d'utiliser l'index et pas
un scan)

la table a +de 5000000 de rows

set enable_seqscan=true;
SET
explain analyze select * from combinaison_bis where a=11;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------

Seq Scan on combinaison_bis (cost=0.00..104144.32 rows=65198 width=28)
(actual time=12652.61..31637.17 rows=169911 loops=1)
Filter: (a = 11)
Total runtime: 31749.48 msec
(3 rows)

set enable_seqscan=false;
SET
daniel=# explain analyze select * from combinaison_bis where a=11;

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------

Index Scan using a_combinaison_bis_key on combinaison_bis
(cost=0.00..211305.74 rows=65198 width=28) (actual time=111.80..2872.23
rows=169911 loops=1)
Index Cond: (a = 11)
Total runtime: 2976.17 msec
(3 rows)

daniel

ps: pourquoi l'adresse de reply est l'adresse de l'exp. et non l'adresse
de la liste ?