Re: Be

Stéphane Schildknecht a écrit :
| C'est alors le contraire qu'il faut envisager. Ne faire que les
| "insert" (Quitte à utiliser de fausse données pour les celles
| récupérées par les différents select).

Cela va être difficile car certains des SELECT servent uniquement à
récupérer les identifiants uniques attribués (via une séquence) lors
de l'insertion des précédentes données et les contraintes d'intégrité
font que je ne peux référencer dans les tables que des données
existant réellement.

Pour que je puisse me passer des SELECT sans toutefois altérer la
structure de la base, il va falloir que je modifie lourdement mon
script ; il ne s'agit plus de commenter quelques lignes...

Pour revenir sur ton idée première, est-ce à ton avis intéressant et
pertinant de rejouer les données précédemment intégrées, sans
effectuer de nouvelles insertions (comme tu le demandais) mais sans
détruire au préalable les données déjà insérées ?

| Notre idée de base est celle d'une influence du gestionnaire de
| processus de l'OS sur le moteur du SGBD.

A ce point !? Je n'y crois pas vraiment car la machine n'a que cela à
faire. Les seules applications réellement actives sont le serveur
PostgreSQL et mon script Perl. Or, j'ai un facteur 100 entre les
meilleures et les pires performances. A qui l'ordonnanceur pourraît-il
bien filer du temps CPU ?

Ceci étant, comme je n'ai pas mieux à proposer, je vais faire ce que
tu suggères. J'envoie les résultats dès que je les ai.

| <parenthèse>
| Tu sais ce qu'il te dit le bougre ? ;-)
| </parenthèse>

(c:

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !