From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> |
Cc: | pgsql-fr-generale(at)lists(dot)postgresql(dot)org |
Subject: | Re: traitement par lots et sequence |
Date: | 2019-06-12 10:48:09 |
Message-ID: | 4b669c44-08a4-4f3a-9deb-3756de193a85@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
CRUMEYROLLE Pierre wrote:
> 3 - boucle sur tous les id de mère
> for i in liste_id_mere
> {
> insertion d'un paquet de j filles pour une mère
> insert into T_filles idFils,idMere,datamere values
> ((j,i,dataf1),(j,i,dataf2),(j,i,dataf3), .... (j,i,datafn));
> }
> }
>
> je suis obligé de faire de l'insert par batch car l'insertion
> unitaire postgresql n'est pas top , seul le traitement par lots donne
> des perfs convenables.
N'oubliez pas de faire tout ça dans la même transaction, sinon c'est
les commit intermédiaires implicites qui ruinent les performances.
Indépendamment de ça, effectivement envoyer beaucoup d'INSERT avec peu
de données à chaque fois n'est pas ce qu'il y a de plus efficace, mais
au vu de l'étape 3 ci-dessus, on ne voit pas pourquoi cette boucle FOR
ne construit pas un seul INSERT par accumulation de VALUES, et
l'exécute une seule fois en dehors de la boucle. Puisque que ça
insère toujours dans la même table et toujours avec les même colonnes
cibles.
Et une fois qu'on en est là dans le raisonnement, on peut se demander
aussi si ça ne pourrait pas faire un COPY dans la table cible au lieu
d'un INSERT géant, ce qui serait plus rapide aussi en permettant
notamment un effet de pipeline entre le client et le serveur.
Cordialement,
--
Daniel Vérité
From | Date | Subject | |
---|---|---|---|
Next Message | Emmanuel BEZAGU | 2019-06-12 11:20:18 | Re: traitement par lots et sequence |
Previous Message | CRUMEYROLLE Pierre | 2019-06-12 09:36:47 | Re: traitement par lots et sequence |