index sur un champ date dans postgresql

Le
Etienne SOBOLE
salut j'ai cette requete

explain analyse select sum(fact_montant) from as400fact inner join as400com
on as400fact.idcom = as400com.idcom where fact_date >= '20070101' and
bdc_group = '24013271';

qui me donne
Aggregate (costQ6.58..516.58 rows=1 width=8) (actual
time†55.762..8655.764 rows=1 loops=1)
-> Nested Loop (cost=0.00..516.58 rows=1 width=8) (actual
timec25.579..8655.296 rowsU loops=1)
Join Filter: ("inner".idcom = "outer".idcom)
-> Index Scan using ek_as400com_bdcgroup on as400com
(cost=0.00..4.84 rows=1 width=4) (actual time=0.064..10.432 rowsy3
loops=1)
Index Cond: ((bdc_group)::text = '24013271'::text)
-> Seq Scan on as400fact (cost=0.00..506.30 rowsC5 width)
(actual time=1.832..9.714 rowsG6 loopsy3)
Filter: (fact_date >= '2007-01-01 00:00:00'::timestamp
without time zone)
Total runtime: 8655.852 ms
(8 rows)

Mais que faut il faire pour mettre un index sur la colonne fact_date ???
un simple
CREATE INDEX ek_as400fact_factdate ON as400fact (fact_date);

ne change pas grand chose. car l'index n'est pas utilisé !!!

help !!!
merci
Etienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Mevzek
Le #21840161
Le Mon, 12 Mar 2007 10:14:08 +0100, Etienne SOBOLE a écrit :
ne change pas grand chose. car l'index n'est pas utilisé !!!



S'il n'est pas utilisé c'est que le système estime que cela ira plus
vite sans. Utiliser un index n'est pas toujours plus rapide.

D'après votre requête, si les statistiques sont correctes, votre table
as400fact a 435 lignes, soit donc trop peu de lignes pour justifier un
index (un accès séquentiel ira plus vite)

Cela dépend donc du contenu de la table :
- il faut ne pas oublier le ANALYZE régulier
- et éventuellement augmenter les statistiques pour l'attribut indexé.

Si ce n'est pas déjà le cas, des index sur les attributs idcom
pourraient peut-être être utiles.
Vous pouvez aussi essayer de reecrire votre requête avec une
sous-requête à la place de la jointure, ca donnera peut-être d'autres
résultats (en termes de performances).

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Dépêches sur le nommage
Etienne SOBOLE
Le #21840151
Ok. merci.

j'ai effectivement réécrit la requete et cela a tout changé !
Etienne

"Patrick Mevzek" news:
Le Mon, 12 Mar 2007 10:14:08 +0100, Etienne SOBOLE a écrit :
ne change pas grand chose. car l'index n'est pas utilisé !!!



S'il n'est pas utilisé c'est que le système estime que cela ira plus
vite sans. Utiliser un index n'est pas toujours plus rapide.

D'après votre requête, si les statistiques sont correctes, votre table
as400fact a 435 lignes, soit donc trop peu de lignes pour justifier un
index (un accès séquentiel ira plus vite)

Cela dépend donc du contenu de la table :
- il faut ne pas oublier le ANALYZE régulier
- et éventuellement augmenter les statistiques pour l'attribut indexé.

Si ce n'est pas déjà le cas, des index sur les attributs idcom
pourraient peut-être être utiles.
Vous pouvez aussi essayer de reecrire votre requête avec une
sous-requête à la place de la jointure, ca donnera peut-être d'autres
résultats (en termes de performances).

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Dépêches sur le nommage
Publicité
Poster une réponse
Anonyme