Skip site navigation (1) Skip section navigation (2)

Re: En

From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: En
Date: 2005-09-16 09:14:12
Message-ID: 20050916091412.GA31480@newtech.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Bonjour,

Xavier Poinsard a écrit :
| Sébastien Dinot a écrit :
| > Autrement dit, il faut que je détruise et régénère mes requêtes
| > préparées à la fin de chaque boucle. Outchh...
|
| Pas forcément, il faut peut-être simplement éviter de mettre à jour
| les statistiques avec ANALYZE lorsque la table est vide ou recréer
| une fois les Prepared statements lorsque la table a atteint un
| certain remplissage.

Comme promis, voici donc la conclusion de l'affaire. Xavier avait
apparemment vu juste mais la correction du problème m'a donné du fil à
retordre et je ne suis pas complètement satisfait de la méthode que
j'ai fini par utiliser, à savoir une déconnexion régulière de la base.

En effet, après avoir adapté mon script Perl, je me suis aperçu que
DBI (le module générique d'accès aux bases de données que j'utilise)
ne regénérait pas les requêtes préparées : les requêtes mises en cache
persistaient malgré l'ajout des attributs idoines dans l'API de DBI.
Du coup, point d'amélioration de performance... )c:

Je n'ai trouvé aucun moyen de détruire proprement et sûrement ces
requêtes malgré de nombreux essais, diverses lectures et de longues
recherches sur le net.

Je me suis donc résigné à me déconnecter régulièrement de la base (DBI
détruit alors tous les handles) puis à me reconnecter dans la foulée.

Comme je l'ai déjà expliqué, après chaque traitement d'un lot de 10000
lignes, mon script « fait le point » et décide ou non d'effectuer
individuellement chaque opération de maintenance (VACUUM, ANALYZE,
CLUSTER, etc.).

De manière complètement arbitraire (et certainement critiquable...
avis bienvenus), j'ai décidé de réinitialiser la connexion après :

- insertion d'au moins 1 enregistrement dans une table qui en
  contenait moins de 40000 (je vérifie que j'ai inséré au moins 1
  enregistrement car mon script alimente séquentiellement plusieurs
  tables et certaines restent donc vides un bon moment : il serait
  idiot de se reconnecter à cause d'elles) ;

- le script vient d'insérer 200 000 tuples.

Autrement dit, alimentant une table initialement vide, je réinitialise
la connexion après :

 10 000 tuples insérés
 20 000 tuples insérés
 30 000 tuples insérés
 40 000 tuples insérés
240 000 tuples insérés
440 000 tuples insérés
640 000 tuples insérés
840 000 tuples insérés
etc.

Ca ne me satisfait pas mais c'est sacrément efficace : quelque soit le
volume de données en base (en fait, jusqu'à 7 millions de tuples),
insérer 10 000 enregistrements prend entre 10 et 15 secondes (sauf
pour les 10 000 premiers qui requièrent 42 secondes).

Une fois encore, tous les commentaires sont les bienvenus (et pas
uniquement sur IRC hein les gars !? moi, je n'y suis jamais sur IRC).

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 !

In response to

  • Re: En at 2005-09-13 13:48:13 from Xavier Poinsard

pgsql-fr-generale by date

Next:From: CHARABOUSKA ChristelDate: 2005-09-16 16:48:22
Subject: Sauvegarde à chaud
Previous:From: Jean-Max ReymondDate: 2005-09-16 07:19:23
Subject: Re: Installation sur FC4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group