Re: planer en delire !!!

Hervé Piedvache wrote:

>Daniel,
>
>Le Mercredi 27 Août 2003 16:03, Daniel a écrit :
>
>
>>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.
>>
>>
>
>Elle represente quel volume de données ta table, et quelle disparité dans les
>données de la colonne a ?
>Dans certain cas il est plus intéressant de ne pas utiliser l'index pour le
>planner ... L'utilisation d'index n'est pas forcément la meilleure solution
>pour lui ...
>
>Peux tu nous faire un explain de cette requête ?
>
>Cordialement,
>
>
voila, voila

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