Jeg skal opdatere tabeller med 1 eller 2 milliarder rækker med forskellige værdier for hver række. Hver kørsel foretager ~100 millioner ændringer (10%). Mit første forsøg var at gruppere dem i transaktioner på 300K opdateringer direkte på en specifik partition, da Postgresql ikke altid optimerer forberedte forespørgsler, hvis du bruger partitioner.
- Transaktioner af en masse "OPDATERING minTabel SET myField=value WHEREmyId=id"
Giver 1.500 opdateringer/sek. hvilket betyder, at hver løbetur vil tage mindst 18 timer. - HOT opdateringsløsning som beskrevet her med FILLFACTOR=50. Giver 1.600 opdateringer/sek. Jeg bruger SSD'er, så det er en dyr forbedring, da den fordobler lagerstørrelsen.
- Indsæt i en midlertidig tabel med opdateret værdi og flet dem derefter med OPDATERING...FRA Giver 18.000 opdateringer/sek. hvis jeg laver en VACUUM for hver partition; 100.000 op/s ellers. Cooool.
Her er sekvensen af operationer:
CREATE TEMP TABLE tempTable (id BIGINT NOT NULL, field(s) to be updated,
CONSTRAINT tempTable_pkey PRIMARY KEY (id));
Akkumuler en masse opdateringer i en buffer afhængigt af tilgængeligt RAMNår den er fyldt, eller skal skifte tabel/partition eller fuldføres:
COPY tempTable FROM buffer;
UPDATE myTable a SET field(s)=value(s) FROM tempTable b WHERE a.id=b.id;
COMMIT;
TRUNCATE TABLE tempTable;
VACUUM FULL ANALYZE myTable;
Det betyder, at en løbetur nu tager 1,5 timer i stedet for 18 timer for 100 millioner opdateringer, inklusive vakuum. For at spare tid er det ikke nødvendigt at lave en støvsuger FULD til sidst, men selv en hurtig almindelig støvsuger er nyttig til at kontrollere dit transaktions-id på databasen og ikke få uønsket autostøvsugning i myldretiden.