Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
CrazyCat
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
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
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
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:
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:
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:
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
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...
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
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
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
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 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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Fos Pat
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.
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.
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.
