select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
- y a t il un moyen de faire comprendre a postgresql qu'il serait
plus judicieux d'utiliser un index.
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
- y a t il un moyen de faire comprendre a postgresql qu'il serait
plus judicieux d'utiliser un index.
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
- y a t il un moyen de faire comprendre a postgresql qu'il serait
plus judicieux d'utiliser un index.
Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais 60
a la suite en specifiant les idtable un par un.
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
merci
Etienne
Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais 60
a la suite en specifiant les idtable un par un.
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
merci
Etienne
Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais 60
a la suite en specifiant les idtable un par un.
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
merci
Etienne
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable. alors il est
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable. alors il est
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable. alors il est
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
A +
WebShaker a écrit :Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
A +
WebShaker a écrit :
Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
A +
WebShaker a écrit :Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
WebShaker a écrit :Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
WebShaker a écrit :
Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +
A partir du moment ou il y a des valeurs discrètes multiples, aucun
index ne peut s'activer de manière bénéfique.
Vous feriez mieux de mettre ces valeurs dans une table temporaires
indexée et de faire des jointures dessus.
WebShaker a écrit :Salut
j'execute une requete
select max(e_date) FROM table WHERE idtable IN (xx, xx, xx, xx, ...)
byzarrement PostgreSQL n'utilise par l'index sur idtable.
alors il est vrai que j'ai 60 valeurs dans le IN.
le probleme c'est que la requete prend plus de temps que si j'en fais
60 a la suite en specifiant les idtable un par un.
Normal, même avec un UNION ALL cela sera plus vite car là il est
possible d'utiliser un idex sur chacune des 60 requêtes !
Une fois la requete executer une premiere fois (ca prend 250 secondes
quand meme) les executions suivantes ne prennent plus que 4 secondes.
Normal, le plan doit être en cache et les données aussi. Quel est la
volume de la BD et de la RAM ? Est du 32 ou 64 bits ?
Donc j'ai deux questions:
- y a t il un moyen de faire comprendre a postgresql qu'il serait plus
judicieux d'utiliser un index.
Strictement aucun intérêt ! Aucun gain !!!
- peut on supprimer les caches de postgres afin de faire des tests
réalistes dans des conditions réel d'une première utilisation.
C'est d'une grande stupidité : les bases de données fonctionne
essentiellement en cache (donc RAM) le disque n'est là que pour assurer
la persistance en attendant des techniques plus rapide comme les flash
disk.
merci
Etienne
Lisez les article que j'ai écrit sur l'optimisation dans mon site web !
A +