vacuum dauert "ewig"

moin moin,

mein erster post hier: ich habe eine postgis 8.4 db, die eigentlich ganz gut rennt. ich “schaffe” da im openstreetmap-umfeld.

vor einigen tagen habe ich in einer tabelle ca 28.000.000 datensätze von ca 80 mio gelöscht und danach nen vacuum angestoßen.
erst vacuum analyze und später abgebrochen und jetzt nur einen vaccum verbose.
den full wollte/will ich auf später verschieben, damit ich solange noch an die daten rankomme.

das problem: es dauert. war mir klar.
aber er geht MEHRFACH durch die daten mit jeweils leicht anderen werten. und das kann ich mir derzeit nicht erklären.

log: gis=# vacuum verbose nodes;
INFO: vacuume »public.nodes«
INFO: Index »pk_nodes« gelesen und 2796004 Zeilenversionen entfernt
DETAIL: CPU 2.74s/15.43u sec elapsed 69.02 sec.
INFO: Index »idx_nodes_geom« gelesen und 2796004 Zeilenversionen entfernt
DETAIL: CPU 30.81s/18.95u sec elapsed 3852.82 sec.
INFO: »nodes«: 2796004 Zeilenversionen in 36976 Seiten entfernt
DETAIL: CPU 1.03s/0.54u sec elapsed 43.01 sec.
INFO: Index »pk_nodes« gelesen und 2795930 Zeilenversionen entfernt
DETAIL: CPU 4.16s/16.42u sec elapsed 233.53 sec.
INFO: Index »idx_nodes_geom« gelesen und 2795930 Zeilenversionen entfernt
DETAIL: CPU 31.76s/20.53u sec elapsed 3919.15 sec.
INFO: »nodes«: 2795930 Zeilenversionen in 35212 Seiten entfernt
DETAIL: CPU 0.90s/0.53u sec elapsed 40.88 sec.
INFO: Index »pk_nodes« gelesen und 2795959 Zeilenversionen entfernt
… u.s.w. bis aktuell
INFO: Index »pk_nodes« gelesen und 2795971 Zeilenversionen entfernt
DETAIL: CPU 4.73s/13.16u sec elapsed 256.87 sec.

das ist der output von ca 8 stunden und der rödelt immer noch.

ich habe natürlich dreimal gecheckt, ob auf meiner kiste noch ne anwendung aktiv ist, die “klammheimlich” noch in die db reinschreibt, aber da ist nix.

frage: ist das normal? oder hab ich ein problem?

gruss
walter

VACUUM ist langsam. Probier mal CLUSTER aus, um die Tabelle neu schreiben zu lassen, das sollte um Längen schneller gehen.

In PostgreSQL 9.0 wurde die Funktionalität dahingehend geändert, dass ein VACUUL FULL hintenrum ein CLUSTER aufruft. In früheren Versionen musst du das manuell erledigen.

danke,
inzwischen ist er durch. i
ich hatte mich nur darüber gewundert, dass er mehrmals durchrennt und dann noch mit verschiedenen werten.
schließlich war die db ja “read-only”, da keine anwendung da was änderte, geschweige was hinzugefügt hat.
war halt komisch ;(

cluster kommt auch noch dran, da dies bei geo-daten sinn macht. sollte ich VORHER nen vacuum full machen oder gleich in einem rutsch?

ich kenn mich halt mir relativ großen dbs noch nicht so gut aus. diese hier ist ca 40 G-breit :wink:

gruss
walter

ach ja: 9.0 ist mir noch etwas zu füh.

CLUSTER macht im Prinzip das gleiche wie VACUUM FULL, nur schneller.

Unterschied: VACUUM FULL reorganisiert jeden Bereich der Tabelle und fasst diese zusammen, CLUSTER schreibt die Tabelle in einem Durchgang neu.

40 GB ist nun nicht wirklich viel :wink:

danke, dann spar ich mir den vacuum full.