Re: PostgreSQL 8. 1 et grosse volumétrie

Bonsoir,

david delannoy a écrit :
> J'avoue être dérouté par ce problème. Auriez-vous des pistes?

La description du contexte n'est pas exhaustive mais je me risque à une
hypothèse :

Vous injectez 500 Go de données dans une base vide et vous utilisez
une requête préparée pour optimiser l'insertion.

Si tel est le cas, vous êtes dans la situation que j'ai connue il y a un
peu plus de trois ans et dont j'avais fait part ici même. Une bonne âme
m'avait alors donné la clé de l'énigme.

L'optimiseur de PostgreSQL sélectionne la stratégie d'attaque de la base
lors de la préparation de la requête. Comme vous partez d'une base vide,
il décide d'opter pour un parcours séquentiel des tables car il serait
contre-productif de passer par les index dans ce cas. Ce raisonnement
qui vaut pour 1 000 enregistrements, ne tient plus pour 1 000 000. Du
coup, au fur et à mesure que vos tables grossissent, les temps de
traitement s'allongent. Vous insérez 100 données par seconde, puis 10
puis 1 avant de mettre 10 secondes pour en insérér une puis 100 puis
1000, etc.

Peut-être que dans votre cas, le pilote intègre un time-out qu'il finit
par atteindre.

Si votre problème est bien celui-ci, quel est le remède ? Il y a trois
ans, j'ai pris le parti de clore la requête préparée toutes les 10 000
insertions pour la ré-ouvrir dans la foulée et mon problème s'est
volatisé. Mais je ne suis pas l'actualité de PostgreSQL de très près.
Peut-être qu'aujourd'hui une solution plus élégante et satisfaisante
existe.

Voilà, en espérant que cela vous aidera.

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 !