Reprise du message précédent :

Tu crois pas qu'on montre nos beaux visages aux premières venues, non mais ho On est pas des hommes faciles, nous

ça te semble normal que le plus gourmand en ressources ne soit pas le plus rapide ?  
 
Dans un autre registre, ça te semble normal qu'oracle soit à peu près 3 fois plus lent que SQL Server sur la même machine lorsqu'on utilise une transaction (alors qu'ils ont des perfs équivalente quand on envoit les requètes en bloc) ?

bha si
 
enfin je crois ...
 
peu être pas pour tous, en fait ... [:meganne-qui-encore-changé-son-smiley-et-qui-fait-chier-:o]
 
 
n'empêche que c'est sympa de connaître le minoi des gens avec qui on discute

 
Goliath aurait beaucoup a dire la dessus
 
 

 
ça va pas ! je peux po kon crois que je suis progueuse

nan mais là non quoi ...
 
 
 
 
je suis déçu
 
dodo

ya des exceptions quand même

Je t'aime bien chris mais c'est pas vraiment le moment de faire de l'esprit

 
pas spécialement normal, mais ca ne me semble pas non plus anormal.    
 
 

 
non, ca ne me semble pas normal ( ni anormal d'ailleurs). j'ai jamais eu l'occasion de faire ces benchs  , renseignes toi sur l'applicatif oracle pour savoir si c'est lié au SGBD.
t'as essayé en procédure ? c'est encore ce qui est le plus rapide  ( en tt cas c'est le cas sur SQL Server )

J'ai fait des recherches sur le net, mais j'ai rien trouvé d'intéressant
 

j'aimerai rester au SQL classique, notre logiciel doit tourner sur plusieurs SGBD et je tiens à limiter au maximum le code spécifique à chaque SGBD.

barrique > et en reformulant ta requête t'as pas moyen de gagner du temps ?
 
edit : pour un insert ca va être dur
 
 
>>>> t'as des index sur tes champs ?

tu voudrais pas m'aider plutot que de poster tes images moches et trop compressées ?

Oui et ils sont indispensable (ben oui, il faut aussi que ça se charge vite cette connerie).

ah tiens chui pu ban d'image

gni? Qu'entends-tu par "se charger"?

 
ben voilà ....  elle peut se faire là, la différence
 
tu veux pas dupliquer ta table (pour test) et faire un bench ss les index ?

 
l'est vraiment trop trop laide cette tof

Non. Tes problèmes de SGBD, j'm'en contrecogne, surtout un vendredi soir à 0h26

Quand je démarre l'application, il faut que je charge ces données (il faut que je les récupère si tu préfères).

Ok, et ce sont des insert massifs que tu fais? ca correspond à quel volume de ta db?

OK, va mourrir tout nu accroché à un lampadaire alors

J'ai BESOIN de ces indexes, je ne peux pas les virer.

 
oui, j'ai compris .... l'idée c'est d'identifier la cause dans l'immédiat  

oui, je fais plusieurs milliers d'insert (voir plusieurs dizaine de milliers) dans 2 tables.

 

 
identifions, identifions

plusieurs milliers, ca veut rien dire. en volume de la DB, ca fait combien? et en volumes des tables concernées?

 
nostalgie du beau pays et de ses vedettes emblématiques

ok, je teste sans index (pouark, une table sans clef )

A vue de nez, je dirais entre 100 et 300 octets par enregistrement.

Bon, on va poser la question autrement...
 
Quel pourcentage de la DB, et des tables?

rooh la bande de touristes néerlandais dans un club med de Crête !

Ca l'fait, hein ?

j'en sais rien

 
une certaine vision de l'enfer

non, à un échantillon de sperme /o\

t'as dû oublier les JO de cet été dans ton calcul.

Ouais mais pas avec le foute.
 
Sinon, les Français ont battu la Pologne en Ligue Mondiale de volley, si ça peut remonter le moral des gros cons de fouteux

Taiche aime bien les JO, c'est une des rares périodes où on parle de son sport fétiche, la course en sac

RAAAAAAHH  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
un revenantu !

ça vient pas des indexes