Re: UPDATE de plus en plus long

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)

In response to

Responses

Browse pgsql-fr-generale by date

  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