Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

index sur un champ date dans postgresql

2 réponses
Avatar
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 (cost=516.58..516.58 rows=1 width=8) (actual
time=8655.762..8655.764 rows=1 loops=1)
-> Nested Loop (cost=0.00..516.58 rows=1 width=8) (actual
time=6325.579..8655.296 rows=55 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 rows=793
loops=1)
Index Cond: ((bdc_group)::text = '24013271'::text)
-> Seq Scan on as400fact (cost=0.00..506.30 rows=435 width=12)
(actual time=1.832..9.714 rows=476 loops=793)
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

2 réponses

Avatar
Patrick Mevzek
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Avatar
Etienne SOBOLE
Ok. merci.

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

"Patrick Mevzek" a écrit dans le message de
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>