Performanceprobleme bei Update

Hallo zusammen, ich muss ein paar Updates auf große Tabellen machen und das dauert viel zu lange. Zunächst zu den Tabellen:

CREATE TABLE verordnung_151
(
monat smallint NOT NULL,
mandant smallint NOT NULL,
lnr integer NOT NULL,
pos smallint NOT NULL,
...
autidem smallint NOT NULL,
...
  CONSTRAINT pk_verordnung_151 PRIMARY KEY (monat, mandant, lnr, pos) USING INDEX TABLESPACE idx
)WITHOUT OIDS  tablespace data;


CREATE TABLE tmp_autidem
(
  monat smallint NOT NULL,
  mandant smallint NOT NULL,
  lnr integer NOT NULL,
  pos smallint NOT NULL,
  pzn integer NOT NULL,
  autidem smallint,
  CONSTRAINT tmp_autidem_pkey PRIMARY KEY (monat, mandant, lnr, pos) USING INDEX TABLESPACE idx
) 
WITHOUT OIDS TABLESPACE data;

Beide Tabellen sind nach dem Primärschlüssel geclustered, vacuum und analyze ist gemacht. Die Tabele Verordnung hat ca. 6,5 Mio Sätze (Monat 151). tmp_autidem 107 Mio Sätze (Monate 146 -163), da auch noch andere partitionen gemacht werden müssen.

Nun das Update:

update verordnung_151 set autidem=r.autidem
from tmp_autidem r
where verordnung_151.monat=r.monat and verordnung_151.mandant=r.mandant
and verordnung_151.lnr=r.lnr and verordnung_151.pos=r.pos and r.monat=151;

Der Ausführungsplan sieht eigentlich wie erwartet aus, was den Mergejoin betrifft. Was ich hier nicht ganz verstehe ist die Sortieroperation, da die Daten ja bereits sortiert vorliegen

explain update ...
Merge Join  (cost=3022261.56..3523750.32 rows=22639491 width=77)
  Merge Cond: ((verordnung_151.lnr = r.lnr) AND (verordnung_151.pos = r.pos) AND (verordnung_151.mandant = r.mandant))
  ->  Sort  (cost=1237317.83..1253720.87 rows=6561216 width=75)
        Sort Key: verordnung_151.lnr, verordnung_151.pos, verordnung_151.mandant
        ->  Seq Scan on verordnung_151  (cost=0.00..202867.20 rows=6561216 width=75)
              Filter: (151 = monat)
  ->  Sort  (cost=1784943.73..1801730.97 rows=6714898 width=12)
        Sort Key: r.lnr, r.pos, r.mandant
        ->  Bitmap Heap Scan on tmp_autidem r  (cost=140494.86..908752.08 rows=6714898 width=12)
              Recheck Cond: (monat = 151)
              ->  Bitmap Index Scan on tmp_autidem_pkey  (cost=0.00..138816.14 rows=6714898 width=0)
                    Index Cond: (monat = 151)

Das Update hat für diese Partition ca. 7 Stunden gedauert. (Zum Vergleich: der MS SQL-Server, von dem ich die Daten migriert habe braucht ca. 5 min bei etwas schlechterer Hardware.) Also irgendwas ist hier faul.
Wenn ich mir während des Updates ein top anschaue, dann kann ich sehen, dass über 40-45% der CPU wa sind.

Ich habe auch versucht, vorher aus tmp_autidem nur den Monat 151 herauszuziehen und auch mit exlusive Tablock zu arbeiten, leider ohne Erfolg.

Vielleicht noch etwas zur Hardware:
2xPIII Tualatin 1,4GHz
2GB RAM
Tabelspace Data und IDX liegen je auf einem RAID5 aus je 7 Platten. pg_xlog liegt auf einem separaten RAID1.

Was kann man hier machen?

Auf die Schnelle fällt mir da das ins Auge:

Seq Scan on verordnung_151  (cost=0.00..202867.20 rows=6561216 width=75)
              Filter: (151 = monat)

Möglicherweise könnte in extra Index auf der Monatsspalte helfen.


Andreas

Außerdem: ein EXPLAIN ANALYSE ist hilfreicher, weil es zeigt die realen Kosten mit an.

Andreas