Reprise du message précédent :
Bon mon test, c'est effectivement qu'une seule connexion qui balance la sauce. Mon but est juste de comparer par rapport à ce que j'ai obtenu avec SQLite, dans les mêmes conditions. Et je ne veux pas faire de 100 inserts/s volontairement, je veux voir jusqu'où il peut aller. Le peu que j'ai pu voir, c'était du 700 ins/s environ. Mais il me faut quand même ma base entière pour faire mes tests de select !!!    
bref, je cherche du côté du timeout, mais pour l'instant, rien trouvé...
Ah au fait un truc con : est-ce que les insert sont plus rapides s'ils sont tous regroupés dans une même transaction ou est-ce que c'est pareil, voire plus lent que sans transactions ?
parce qu'avec SQLite, c'est TRES TRES nettement plus rapide avec transaction, car ce con ouvre et ferme une transaction pour chaque insert sinon.

bah ça dépend si t'es en auto-commit ou pas. Mais surtout, si tu veux faire un insert massif pour faire des tests ensuite dessus, désactive les contraintes et les index, fait tes insert et puis remet-les. Ce sera nettement plus rapide.

Bon, je vais essayer de couper mon test en 2 connexions. A la moitié, paf je coupe la connexion et je la réouvre, on va bien voir. Sans oublier un pti COMMIT avant de fermer la connexion, sinon, la haine
j'ai pensé à ton astuce de virer les contraintes et les index, mais ça fausse les tests, toujours pareil : dans la vraie vie, on ne virera pas les index à chaque insert, donc bon...

oui, mais dans la vrai vie, tu le feras pas non plus les 700 insert/sec que tu fais dans ton test...

Bon déjà j'avais des fuites mémoire dans tous les sens, à chaque fois que j'exécutais une requête. En gros, le résultat retourné par chaque requête était alloué par la lib C, mais je les libérais jamais... Ca devrait déjà aller mieux.

C'est sur que je ferai pas les 700ins/s (quoique, par moments...), mais je vais pas me pourrir une journée pour faire un seul test. Et en plus, en insérer 100 par seconde, ça n'aurait aucun intérêt, je sais très bien qu'il est capable de le faire.
En tout cas, merci quand même pour toutes ces réponses, je viens de m'apercevoir que je ne l'avais pas encore une seule fois dans ce sujet.  

Moi je vote pour un rollback segment fault

 
Ce test ne veux rien dire :
 
Pour ce qui est de faire un select sur une seule table, et des insert dans une seule table, Oracle est plus rapide à l'insert que SQL Server, mais on observe l'inverse au moment des select.
 
Donc de toute façon, d'un sgbd à l'autre, le même test n'est pas fiable. Surtout quand il s'agit d'un test aussi simple.

PS: et dans tous les cas, si t'as un problème de perfs, une barrette de 1 Go de DDR plus un disque 15Ktrm dans le serveur, et l'affaire est réglée, pour moins de 500 €, donc faudrait pas y passer trop de temps non plus hein !

Ben le truc c'est que je suis stagiaire, et c'est un morceau de mon stage donc ce que je suis en train de faire. Donc le temps... du moment que je finis les trucs qu'on m'a donné à faire, c'est bon.
De plus, je bosse pas directement sur le serveur, mais sur une machine moins puissante, donc les perfs seront a priori meilleures sur le serveur. Mais je pense que les inserts, ça ira niveau perfs. Il faut voir pour les select surtout, car c'est ça qui était catastrophique avec SQLite. Un select (qui sera souvent exécuté) qui prend 80 secondes pour s'exécuter, c'est pas acceptable (cas extrême bien entendu).

Euh au fait gizmo, j'avais pas compris quand tu m'as répondu au sujet de mes pbs d'accents : je croyais que tu parlais des accents foirés dans le message d'erreur que j'ai copié/collé, qui provenaient d'une invite de commande MS/DOS.
C'est laquelle la locale à définir pour passer en "latin" ? client_encoding ?

A priori, je dirais oui. A moins que ce soit l'encodage au niveau serveur qui soit mal configuré également.

Donc je mets ça dans mon fichier postgresql.conf selon ce que t'avais dit tout à l'heure :
client_encoding = C
 

Ben je ne comprendrai désespérément jamais les gens qui font optimiser (même à un stagiaire) une base de 500 Mo.
En effet, vu la taille, quelquesoit la machine et la merdicité absolue de l'architecture de la base, avec un ou deux index biens placés, n'importe quel SGBD (même SQL Lite je suis sûr, puisque Access fait mieu que ce que tu dis) arrivera tout à fait a tourner convenablement.
 
Les questions d'optimisation, ça se pose quand on a un gros serveur avec un SAN au cul, et que ça commence à ralentir : entre passer 15 jours de consultant Oracle payé 1500 € jour, ou dépenser 1 M€ pour un nouveau serveur, on tente l'optimisation. Mais quand on est sur une machine de "monsieur tout le monde", franchement, je reste sur mon derrière quand je vois des gens passer des journées entières à tenter de passer de 5 secondes à 4 secondes, alors qu'une upgrade de matériel, de moins de 1000 € (donc prix forfaitaire d'une journée de DBA junior), permettrait de passer de 5 secondes à 1 seconde...
 
Alors évidement, il y a toujours le cas "qui tue", où 5 minutes "d'optimisation" (enfin... de maintenance), permettent d'éviter de dépenser de l'argent inutilement.
Récement, je ne me souvient plus qui sur ce forum, avait un problème de perfs importante sur un serveur. Il a fait dépenser à sa boîte pas mal d'argent pour passer à du RAID SCSI, et malgré ça, ça ralentissait toujours de façon catastrophique.
Après quelques posts je lui ai proposé de faire une petite intervention simple sur la machine (changement de la façon de gérer la croissance des fichiers de la base, puis defragmentation des disques), et hop ! Là où leserveur mettait 40 secondes à faire une requête ne portant que sur des index uniques, c'est passé à quelques millièmes de secondes...
Mais bon, là c'est pas de l'optimisation, c'est une erreur grossière de configuration et de maintenance.
A partir du moment où le serveur est en place et tourne correctement, tu pourras y passer toutes tes nuits, t'arriveras jamais à améliorer les perfs autant qu'avec un bête upgrade matériel.
 
Et ensuite, pour ce qui est des benchs, je répète que ce j'ai dit hier, d'un SGBD à l'autre, t'obtiens pas du tous les mêmes résultats, et c'est extrêment rarement représentatif.
Pour que ça le soit, il faudrait une appli capable de se connecter à différents SGBD, et la faire tourner en mode "stress", et regarder les différences de résultat, sur le long terme (parceque un test sur une heure peut donner l'avantage à un SGBD, et s'inverser totalement au bout de 2 mois...)

Ben en fait le truc c'est que cette base, pour l'instant, n'existe pas encore. Il existe aujourd'hui un autre système pour faire ce que ma base de données fera peut-être, mais ils veulent le remplacer. Donc en fait, c'est pas super urgent apparemment. Et à mon avis, ils préfèreront garder leur système plutôt que dépenser 1000€ dans une upgrade matérielle sur le serveur. Après, ce ne sont que des suppositions, moi, je n'en sais rien, c'est juste l'impression que j'ai.

Là je comprends plus rien : avec le même schéma de base, Postgres est plus lent que SQLite !!! Je sais plus quoi faire là...
Défragmentation peut-être ?

Bon après défragmentation (le disque était vraiment très très fragmenté, impressionant) léger gain de perfs, surtout en insertions, mais rien d'exceptionnel. J'en concus donc que c'est la machine qui a du mal : dans certains cas de select qui renvoient pas mal de lignes, Postgres est plus lent que SQLite. Postgres étant un peu plus gourmand en ressources et ma machine en ayant peu, je pense que c'est la machine qui limite fortement les perfs (256Mo de RAM, presque toujours pleine ou pas loin). Je vous donnerai des nouvelles si on essaie sur le vrai serveur, là on passe à autre chose pour le moment.

Tous ce que tous nous racontes ne sert à rien tant que tu n'indiques pas la config du serveur, l'architecture de ta base, la taille des tables et les requètes qui coincent...

Dans tout les cas, 256 Mo pour un serveur sous Windows, à moins que ce soit un Win9x (et encore) c'est de toute façon super juste...
 
Pour un 2K ou 2K3, si on veut obtenir des perfs convenables, il faut au grand minimum 512 Mo (histoire que l'OS seul ne remplisse pas la mémoire), et de préférence 1 Go au minimum.

pour une db de 500Mo, meme les 256 devraient etre amplement suffisant.

Ben... Ca dépend de l'OS, parceque de souvenir, notamment 2000, c'est hyper gourmand, donc s'il reste moins de 100 Mo pour la base, ça fait vraiment juste, dans la mesure ou une table entière ne tiendra pas forcément en mémoire...

Evidement, s'il utilise XP ou 2003, le problème se pose pas, ces deux OS prennent moins de 100 Mo si on n'ajoute pas n'importe quoi dessus

tes souvenirs sont errones. 2000 est moins gourmand que XP.

Ah. Plus que 2K3 en tout cas

pas sur. mais encore faut-il comparer les services qui tournent...

Le problème que j'ai c'est qu'il reste même pas 50Mo de RAM libre sur ce PC, donc c'est vraiment juste... Et quant au disque, j'ose pas trop imaginer ce qu'il y a dessus.
Bref, ma base c'est ça :
2 tables, avec quelques index posés où il faut.
1 table ne contient que 100 lignes, l'autre plus de 8600000.
Les requêtes en sélection se font sur la grosse table, et n'ont rien d'exceptionnel.
Des exemples :

Pour les insertions, les perfs restent acceptables, bien qu'un peu faibles à mon goût, mais bon, on s'en fout.
 
La première requête met 28 s à s'exécuter : inacceptable
La deuxième requête met 2.571 ms à s'exécuter : correct
La troisième requête met 1.138 ms à s'exécuter : OK
La quatrième requête est super lente, bien plus que la première : très très très inacceptable, d'autant plus que c'est un des types de requêtes qui sera le plus utile.
 
Pour indication :
 la première requête retourne environ 10000 lignes.
 la deuxième requête retourne environ 100 lignes.
 la troisième requête retourne 1 ligne.
 la quatrième requête retourne 86400 lignes.
 
Or je pense que même 86400 lignes retournées, c'est pas exceptionnel en soi pour le SGBD. D'où mon idée du manque de RAM (entre autres) : en augmentant linéairement le nombre de lignes retournées, la lenteur augmente de façon exponentielle, et encore, je suis gentil. A mon avis, le problème vient de la machine. En plus, Postgres est presque forcément plus gourmand en ressources que SQLite, mais meilleur en performances pour de grosses bases, or là il est plus lent, d'où une fois de plus mon idée du manque de ressources.
 
On fera sûrement les tests sur le vrai serveur plus tard, mais pour l'instant, je suis passé à un tout autre domaine.
 
Si ça peut vous éclairer...

Ben justement, Windows 2000 installe et démarre par défaut une ribembelle de services indésirés, qu'on ne prend généralement pas la peine de désactiver, de peur de planter les services dont on a besoin.
En revanche, 2003 n'installe rien, et on doit installer à la main ceux dont on a besoin (et pour exemple de IIS, c'est une version "light" qui est installée de base, il faut activer un à un les modules désirés, alors que 2000 installe tout, trous de sécurité compris).
 
Sinon, en effet, entre un 2000 et un 2003 correctement configurés, 2003 doit pas être plus léger (quoique). En tout cas, 2003 reste incontestablement infiniment plus rapide sur machine égale, même comparé avec un 2000 bien configuré, donc il faut mieu dans tous les cas un 2003)

Déjà, remplace les >= et <= par un between, c'est plus propre, même si l'impact sur les perfs devrait être nul.
 
Ensuite, as-tu bien un index sur dateServ, et un autre sur indRep,dateServ ? (en cluster pour dateserv, qui semble le plus solicité) et ordered sur indrep,dateserv pour le second)
En effet, avec ou sans index, ça change du tout au tout ! Surtout quand c'est un cluster.
 
Ensuite si ton tablespace est découpé en plein de clusters parceque le disque est à moitié séparé, tu ne pourras en aucun cas obtenir de bonnes perfs.
 
Sinon, essaie de faire une requête bête :
 
select top 10 * from latable
puis
select top 1000 * from latable
 
Si la seconde requête est moins de 100 fois plus lente, alors à priori, c'est bon. Si elle est plus de 100 fois plus lente, vérifie que tu n'as pas des problèmes d'engorgement réseau.

Pour l'instant, pas de souci du côté de l'engorgement réseau : je bosse en local, le serveur est installé sur ma machine, pas sur le "vrai" serveur. Je vais aller voir du côté des index, j'y avais pas pensé aux index clusterisés, je me crois encore avec SQLite   . Bref, merci.

Ha, ben cherche pas plus loin : fait une machine serveur, et une autre pour les requêtes.
 
Quand tu retourne 10000 lignes, tu bouffes les 2 Mo de mémoire qu'il te restait, du coup le SGBD n'arrive plus à terminer sa requête dans de bonnes conditions par manque de mémoire.
 
Je suis persuadé que ça vient de là. A chaque fois que j'ai vait tourner d'autres choses avec un SGBD, j'ai obtenu des performances catastrophiques.

Ben c'est bien ce que je dis : la machine qui m'est attribuée n'est pas du tout faite pour héberger un SGBD d'une taille tout de même un peu conséquente : Windows 2000, peu de RAM, d'autres trucs qui tournent à côté, disque ATA100 5400 RMP, bref, pas top du tout pour ça quoi.
C'est pour ça que j'ai dit qu'il faudra que je teste sur le vrai serveur et que je donnerai des nouvelles.
 
Là j'ai testé avec un index clusterisé sur dateServ, et un index sur indRep,dateServ (d'ailleurs je pense qu'il vaut mieux tout simplement créer un index clusterisé sur indRep car j'ai lu à plusieurs reprises que les index sur plusieurs colonnes sont à éviter), et là, surprise : tout est lent ! Sauf que il y a un truc bien : toutes les requêtes mettent à peu près le même temps d'exécution, c'est à dire 55 secondes environ chacune. Or la 4ème requête mettait un temps encore plus fou avant, de l'ordre de quelques minutes. Donc je suppose que j'ai du me chier quelque part, mais qu'il est possible d'augmenter les perfs.

 
C'est étrange qu'avec des index ça ramme plus. Ceci dit, tant que t'aura pas un PC dédié au serveur, de toute façon, ça sert à rien de faire des plans sur la comète.
 
Sinon, où as-tu lu qu'il ne fallait pas faire d'index sur plusieurs champs ? J'arrive pas à croire que des débiles préconisent ça !

Attention avant j'avais déjà des index, mais j'avais pas pensé aux clusters.
Et puis ça rame pas plus pour toutes les requêtes, yen a une qui va plus vite apparemment. Ce qui est étrange c'est que toutes mettent exactement le même temps à s'exécuter : environ 55 secondes.  
Et sinon, j'ai lu ça notamment sur les "petits papiers de SQLPro" sur www.developpez.com. Il y a tout un tas de conseils pour optimiser son SGBD.
Du moins, j'ai lu qu'il valait mieux éviter.
Ou alors, j'ai encore du me chier quelque part dans mon code étant donné qu'il y a eu quelques petites modifs par ci par là, théoriquement rien de bien méchant, mais bon, la théorie... En plus, la dernière fois que j'avais les requêtes qui mettaient exactement le même temps, c'était un foirage de ma part. Je me disais "waw, ça va vite ! J'ai enfin résolu le pb !" En fait ma base était vide .
Bref, je vais réessayer cet aprèm, les tests de sélection viendront demain normalement.

En tout cas, sûr et certain, c'est n'importe quoi.
 
Les index doivent contenir l'intégralité des champs filtrés de chaque requête (un index par requête) ainsi que ceux qui sont dans le order by.
 
Si t'as une table "personne", et que tu veux resortir les personnes féminines qui ont 20 ans, triées par nom de famille, alors tu fais un index :
 
IDX1(age, sexe, nom)
 
Si dans la même table tu as une seconde requêtes qui doit retourner les personnes qui habitent à paris, sans tri, alors tu feras un second index
 
IDX2(ville)
 
Au contraire, avec X index portant chacuns sur un champ, ne permettra en aucun cas d'améliorer les performances sur des requêtes "complexes" (comme la première) étant donné que le SGBD sera incapable de choisir quel index sera le meilleur. Et dans tous les cas, il sera obligé de faire des rangescan et des tris, même après l'utilisation de l'index choisi, et c'est ça qui prend le plus de temps dans une requête.

Ok, c'est vrai que vu comme ça, ça parait évident qu'il faut créer des index sur plusieurs colonnes.  
C'est donc ce que je vais faire, on verra bien.
 
EDIT : J'ai besoin d'une petite précision :
Est-ce que l'index sur indrep,dateserv peut aussi servir pour les requêtes qui ne sélectionnent que sur indrep (la n°4) ? Ou est-ce qu'il vaut vraiment mieux que je crée aussi un index sur indrep seul ?

Question con, en passant. Que donne les version explain et analyze de tes querys?

pas besoin de créé l'index séparé. ce sera le même que l'arbre prinicpal créé pour l'index sur les 2 colonnes. Par contre, si tu veux faire une query juste sur dateserv, là tu dois ajouter un index.

Ok, merci

Bon, je vais tester sur une autre machine, plus puissante, plus de RAM, surement meilleur disque, mais par contre SQLite uniquement, parce que ils ont pas trop envie d'installer un serveur sur cte machine, et je les comprends, cette machine doit rester "pure", elle est pas du tout là pour ça à la base. Bref, si les perfs sont meilleures sur cette machine avec SQLite, c'est que cela serait probablement meilleur aussi pour Postgres. On va bien voir ce que ça donne.

Bon ben pas d'énorme surprise : c'est déjà bien meilleur qu'avant (2 fois mieux en moyenne), par contre la requête n°4 est aussi lente qu'avant. Je pense que c'est dû au nombre de lignes retournées, qui est bien trop important pour SQLite. En effet, entre la première et la deuxième requete par exemple, on constate une relation de proportionnalité entre le nombre de flignes retournées et le temps d'exécution : 300 fois plus de lignes, 300 fois plus lent.
(Oui d'ailleurs me suis planté dans le nombre de lignes retournées par la 1ère requête, c'est pas 10000 mais 30000).
En revanche, la dernière renvoie même pas 3 fois plus de lignes que la première et elle est 150 fois plus lente. Pourtant j'ai un index sur indRep, comme j'ai un index sur dateServ.
Au fait config de test : 512Mo DDR, Seagate 7200RPM, Athlon 2800+.
On va essayer MySQL 4.1 pour voir, mais sur la vieille config normalement...

C'est vraiment étrange que ce soit aussi lent...
 
Tu peux me donner plus d'infos sur la base, histoire que j'en fasse un clône sur mon serveur ?
 
Genre, y'a combien de "dateserv" pour un "indrep" ?
Que contient "val" ?