Postgres Index

Le
WebShaker
Salut.

dans une de mes requetes j'ai un truc genre

WHERE ((a > 10) AND (b < 20)) OR ((a > 15) AND (b < 18)) OR ((a > 5) AND
(b < 15))

j'ai donc crée un index sur a et un autre sur b et ca va 10 fois plus vite.

mais j'ai aussi essayé d'en créer un (a la place des deux autres) sur a
et b en meme temps

CREATE INDEX mon_index ON ma_table(a, b);

et là rien. postgres ne s'en sert pas ?
pourquoi ???

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
CrazyCat
Le #21917911
Bonjour,

WebShaker wrote:
dans une de mes requetes j'ai un truc genre
WHERE ((a > 10) AND (b < 20)) OR ((a > 15) AND (b < 18)) OR ((a > 5) AND
(b < 15))
CREATE INDEX mon_index ON ma_table(a, b);
et là rien. postgres ne s'en sert pas ?
pourquoi ???



A mon avis, c'est parce que tu ne fais pas une recherche sur (a,b) mais
sur a et b.
Pour ma part, lorsque j'utilise un index de ce genre (en MySQL), c'est
pour une recherche fulltext (match), du genre:
SELECT * FROM table WHERE MATCH (a, b) AGAINST ('value');


--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces : http://www.g33k-zone.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Fos Pat
Le #21917901
WebShaker wrote:
Salut.

dans une de mes requetes j'ai un truc genre

WHERE ((a > 10) AND (b < 20)) OR ((a > 15) AND (b < 18)) OR ((a > 5)
AND (b < 15))
j'ai donc crée un index sur a et un autre sur b et ca va 10 fois plus
vite.
mais j'ai aussi essayé d'en créer un (a la place des deux autres) sur
a et b en meme temps

CREATE INDEX mon_index ON ma_table(a, b);

et là rien. postgres ne s'en sert pas ?



as tu regardé le plan d'execution ?
Comparé celui-ci avec le précédent ?

pourquoi ???



Si Postgresql n'utilise pas un index, c'est qu'il le juge contre
performant.
Postgresql se sert de ses statistiques de la table pour juger de l'intéret
d'un index.
Si les statistiques ne sont pas à jour, il peut faire un mauvais choix.

Après tout dépend du contenu de ta table.

Extrait de la doc concernant les index multi colonnes:

http://www.postgresql.org/docs/8.3/static/indexes-multicolumn.html
WebShaker
Le #21917891
Fos Pat a écrit :
Si Postgresql n'utilise pas un index, c'est qu'il le juge contre
performant.
Postgresql se sert de ses statistiques de la table pour juger de l'intéret
d'un index.
Si les statistiques ne sont pas à jour, il peut faire un mauvais choix.



Mouaip.
Je me suis dis que peut être la recherche multi colonne ne fonctionne
que si on utilise un opérateur
le fait est qu'il est étrange que ça optimise avec 2 indexs et pas un
seul sur les 2 colonnes.

Enfin bon.
Je pense que l'avenir des bases de données, c'est lorsqu'elles seront
capables de vous dire où placer les indexs pour optimiser les requêtes.

Après tout, elles enregistrent l'ensemble des requêtes. elle pourraient
ensuite je ne sais pas comment les analyser pour proposer une solution...

c'est pas une bonne idées ca ;)

Merci en tout cas
Etienne
helios-services
Le #21917881
WebShaker a écrit :
Fos Pat a écrit :
Si Postgresql n'utilise pas un index, c'est qu'il le juge contre
performant.
Postgresql se sert de ses statistiques de la table pour juger de
l'intéret d'un index.
Si les statistiques ne sont pas à jour, il peut faire un mauvais choix.



Mouaip.
Je me suis dis que peut être la recherche multi colonne ne fonctionne
que si on utilise un opérateur >
le fait est qu'il est étrange que ça optimise avec 2 indexs et pas un
seul sur les 2 colonnes.

Enfin bon.
Je pense que l'avenir des bases de données, c'est lorsqu'elles seront
capables de vous dire où placer les indexs pour optimiser les requêtes.

Après tout, elles enregistrent l'ensemble des requêtes. elle pourraient
ensuite je ne sais pas comment les analyser pour proposer une solution...

c'est pas une bonne idées ca ;)





l'avenir (qui a déja 40 ans) est les systems pick et apparenté ou c'est
le SGBD qui met les index de maniére occulte pour optimisé les requétes
Patrick Mevzek
Le #21917871
Le Sat, 25 Jul 2009 07:33:56 +0200, WebShaker a écrit:
Je pense que l'avenir des bases de données, c'est lorsqu'elles seront
capables de vous dire où placer les indexs pour optimiser les requêtes.

Après tout, elles enregistrent l'ensemble des requêtes. elle pourraient
ensuite je ne sais pas comment les analyser pour proposer une
solution...



Sauf que le problème n'est pas statique, mais dynamique : cela ne dépend
pas que des requêtes en elle-mêmes, mais des données stockées aussi, leur
volumétrie, leur répartition statistique, etc.
D'autant qu'elles ne peuvent connaître les requêtes qui vont arriver à
l'avance, alors que vous a priori vous les maîtrisez puisque vous
maîtrisez l'applicatif et pouvez donc faire des tests.

Donc un index donné peut être utile à un instant t pour une certaine
requête et ne plus l'être à un instant t' ultérieur pour la même requête
car les données ont changé.

Ne pas oublier qu'un index n'a pas un coût nul : il faut le mettre à jour
à chaque fois que les données sont mises à jour et il prend de la place,
donc au final c'est un compromis à envisager entre ce coût et des
éventuels gains.

Encore une fois, ce n'est pas une solution magique, certaines requêtes
iront plus vite sans index !

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Fos Pat
Le #21917851
WebShaker wrote:
Enfin bon.
Je pense que l'avenir des bases de données, c'est lorsqu'elles seront
capables de vous dire où placer les indexs pour optimiser les
requêtes.



C'est grosso modo ce que fait la commande explain analyse postgresql.
Suffit juste de savoir lire le resultat.
Publicité
Poster une réponse
Anonyme