Discussion :

[Esil2008]

Bonjour,

J'utilise Postgres 8.3 et je voudrais avoir quelques conseils de votre part pour améliorer les performance d'une requête.

C'est une requête normale, un select avec une clause where avec deux condition sur deux champs différents.
Cette requête prend en moyenne 12s pour récupérer environ 100.000 lignes, sachant que ma table contient en tous 120.000 au plus (elle peut contenir 1 million ou plus)

J'ai crée deux indexes qui correspondent aux deux champs sur lesquels j'effectue ma condition.

Qu'est ce que je pourrais faire pour améliorer mes perf ?

PS : J'utilise Hibernate pour les accès à la BD

Merci

EDIT
Environnement : "Machine de test" XP avec 2 Go de RAM, j'alloue 512 pour eclipse et le reste c'est entre postgres, systeme et les autres programmes, en execution ça monte jusqu'a 3.4Go (ça swap a fond )

[matta]

Bonjour,

100 000 lignes sur 120 000 c'est énorme ce n'est plus la peine
de créer ou d'utiliser des indexes. Les indexes ne sont plus discriminant.
quand il y aura 100 000 / 1 000 000 cela vaudra la peine.

Le problème ce sont les entrés/sorties (i/o) surtout si il y a beaucoup de colonnes.

Question bêtes : as tu besoin des 100 000 lignes ?
utiliser un limit n'est pas possible ? ou alors faire un agrégat ?
ou une procédure stokée

sinon on peut toujours alloué plus de RAM a postgres

[Esil2008]

Merci pour ta réponse,

Au fait, cette requête je l'appelle une seule fois au moment de la création de mon bean. Et j'ai besoin des 100.000 lignes car je me base sur ça pour créer mes structures de données qui me servent pour l'affichage

La table en question se compose de 27 colonnes, je viens de créer 5 indexes mais ça change en rien les perf de cette requête.

A part augmenter la mémoire et changer les parametres de postgres.conf. Pourrais-je faire quelques choses pour gagner quelques secondes ?

Je serais tenter de dire, qu'il vaut mieux récupérer 1000 lignes par requete et traiter ces 1000 lignes en attendant de recevoir la suite. Mais c'est pas trop possible dans mon programme ... Il faudra le changer peut etre !

J'ai une autre question, a votre avis 12s pour 100.000, suis-je dans la moyenne ?

Merci

[bustaf]

Bonjour
Vous n'êtes pas la première personne a evoquer ce genre de désagrément.
Le problème n'est pas lié au moteur .. mais a l'outils SQL qui gère la requête
Si vous demandez par exemple
select * from matable_qui fait_20_million_de_tuples.
le processus va grossir pour finir probablement en erreur.
Par similitude en API backend on gère des tableaux pour les sorties
Pour simplifier
(PQntuples(res) .....) est le nombre d'enregistrements trouvés.
(PQgetValue(res,x,y) (x et y référencent les numéros des champs et les contenus)
Si PQntuples(res) vaut 20000000.l'outil qui vous sert la requête
pourrait subdiviser la tâche afin de la réguler en plusieurs processus.
(plusieurs boucle par pas de x enregistrements).
Chose simple a réaliser si le résultat du SELECT n'est pas un élément conditionnel impliqué dans une requête croisée.
C'est pour cela que la fonctionnalité SQL ne découpe pas automatiquement en pas de xxx
elle ne pas deviner que c'est un sortie d'affichage ou un insertion a la suite
sans relations imbriquées.J'ai regardé rapidement le code source cela semble très complexe de résoudre le problème même avec l'ajout d'un flag programmé pour un SELECT
typé, cela représente un travail considérable de développement.

Ce désagrément peut entrainer des répercutions plus graves en INTRANET
avec un module (à dynamique tierce en PIPE) de compression type (deflate) ou un cryptage clefs (rsa ..) (HTTPS) actif. Apache ne décroche pas et le navigateur n'affiche rien tant que l'entièreté de la requête n'est pas connue...(des temps de réponses laborieux résultants d'une utilisation excessive de la mémoire).

Essayer de gagner quelques secondes ne solutionne pas le problème si votre
charge est amenée a s'accroitre.
Si vous doublez la charge cela ne sera pas 24 ' mais peut être 10 fois plus
Dans votre dernière remarque intelligente vous avez énoncé la voix de la sagesse.
??? (tables temporary)
Bon courage

[Esil2008]

Merci pour votre réponse,

Et bien je crois que je vais devoir changer mon programme pour récupérer 1000 lignes par 1000 et les mettre dans un tampon.

Est ce que vous savez si hibernate propose des méthodes qui font ça ?

Si c'est pas le cas. Pouvez vous m'indiquer un lien ou je pourrais trouver une petite description qui pourrait plus m'éclairer.

Merci

[bustaf]

Bonjour
Hibernatje ne suis pas vraiment initié..
Mais si vous avez quelques notions Java
Vous avez un API JDBC backend qui est très simple
et totalement approprié pour traiter une régulation des charges
Bon courage

[Esil2008]

Merci bq.

J'ai trouvé une solution. Hibernate propose en effet ce genre de traitement.