From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Paul Poirel <poirelpa(at)gmail(dot)com> |
Cc: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: UPDATE de plus en plus long |
Date: | 2013-11-19 14:10:36 |
Message-ID: | m21u2cv5wj.fsf@2ndQuadrant.fr |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Paul Poirel <poirelpa(at)gmail(dot)com> writes:
> En pratique, on a une ligne par année dans cette table.
> On stocke donc l'année (clé primaire) et un compteur. A chaque itération,
> ce compteur est incrémenté.
> Ce comportement pourrait être remplacé par plusieurs séquences (une par
> année).
>
> On a donc des dizaines de millier d'updates sur la même ligne, appelés par
> une même fonction (et donc dans une seule transaction).
> Je vais voir avec le client (qui a conçu l'appli) si il est possible de
> faire autrement.
Créer une table TEMPORAIRE, et faire un INSERT par traitement. En fin de
traitement faire un UPDATE de la table cible en prenant la somme les
insert qui ont été réalisés :
create temp table une_ligne_par_traitement(annee date) on commit drop;
…
insert into une_ligne_par_an(annee_du_traitement_en_cours);
…
update cible c
set compteur = c.compteur + t.somme
from (
select annee, count(*) as somme
from une_ligne_par_traitement
group by annee
)
as t
where t.annee = c.annee;
Le mieux serait bien évidemment de faire ce genre d'UPDATE directement
avec les données à traiter, plutôt que de maintenir les données à
l'unité.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Poirel | 2013-11-20 11:27:59 | Re: UPDATE de plus en plus long |
Previous Message | Paul Poirel | 2013-11-19 14:09:55 | Re: UPDATE de plus en plus long |