# Vacuumdb - habe ich einen Denkfehler?
**URL:** https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686
**Category:** Allgemeines
**Created:** [4. Februar 2023 um 20:07 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686 "2023-02-04T20:07:45Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [4. Februar 2023 um 20:07 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/1 "2023-02-04T20:07:45Z")
Hallo,
regelmäßig starte ich per cron vacuumdb mit:
vacuumdb -z -f -v -d “photosupreme”
So weit läuft das. Was ich nicht verstehe ist, wenn ich später mit:
```auto
SELECT
schemaname, relname,
last_vacuum, last_autovacuum,
vacuum_count, autovacuum_count
FROM pg_stat_user_tables;
```
es anzeigen will wann vacuum bzw. autowacuum gelaufen ist, stehen die Zeilen leer da und die Counter immer auf 0.
An sich dachte ich mir, dass bei den \*last Spalten das letzte Datum eingetragen wird wann es gelaufen ist und bei count insgesamt die Zahl wie viele male es gelaufen ust.
Denkfehler von mir oder muss bei PG 14 es etwas anders aussehen?
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [4. Februar 2023 um 20:40 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/2 "2023-02-04T20:40:22Z")
kann ich nicht bestätigen, hier steht dann der timestamp drin.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [4. Februar 2023 um 20:58 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/3 "2023-02-04T20:58:50Z")
Ich glaube durch Zufall habe ich den Fehler so zu sagen gefunden.
Führe ich eben vacuumdb Befehl aus, also außerhalb von PG, werden die Daten nicht aktualisiert (zumindest bei mir nicht). Führe ich aber vacuum aus psql aus, werden die Daten aktualisiert.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [4. Februar 2023 um 23:29 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/4 "2023-02-04T23:29:12Z")
In den Statistiken wird kein “vacuum full” protokoliert. Das war mein Denkfehler.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [5. Februar 2023 um 07:56 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/5 "2023-02-05T07:56:39Z")
Tatsächlich, ich spreche das mal bei uns intern an.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [5. Februar 2023 um 11:49 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/6 "2023-02-05T11:49:05Z")
also, Peter Eisentraut, einer der Core-Entwickler, meint: “Ich kann mir nicht vorstellen, dass das Absicht ist.”. Das passiert übrigens auch bei VACUUM in psql, wenn es ein FULL ist. Mal sehen, was andere dazu noch sagen, aber ich schätze mal, es ist ein Bug und wird gefixt werden.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [6. Februar 2023 um 07:39 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/7 "2023-02-06T07:39:38Z")
Okay. Die Doku zu `pg_stat_all_tables` sagt:
`last_vacuum` `timestamp with time zone`
Last time at which this table was manually vacuumed (not counting `VACUUM FULL`)
und
`vacuum_count` `bigint`
Number of times this table has been manually vacuumed (not counting `VACUUM FULL`)
Ein Kollege meinte noch: “vacuum full has very little in common with actual vacuum (since 9.0), except for an unfortunate historical name”.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [6. Februar 2023 um 16:40 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/8 "2023-02-06T16:40:11Z")
Dennoch wie Peter Eisentraut wohl angemerkt hat, sollte es die Statistiken auch aktualisieren.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [6. Februar 2023 um 16:50 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/9 "2023-02-06T16:50:00Z")
Jein. Peter war auf Reisen (FOSDEM) und hat nicht allzu tief drüber nachgedacht, denke ich mal. Ein VACUUM FULL ist von der Funktion schon deutlich anders als ein ‘normales’ Vacuum. Bei FULL wird die Tabelle faktisch kopiert, also es geht alle sichtbaren Records durch und schreibt die in eine neue Datei. Daher ist die Tabelle auch komplett gesperrt und Du brauchst temporär und max. noch einmal so viel Platz wie die Tabelle belegt - nämlich dann, wenn alle Tupel sichtbar sind. Ein Vacuum ohne FULL arbeitet komplett anders.
Daher auch der von mir zitierte Satz von John Naylor.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [6. Februar 2023 um 17:13 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/10 "2023-02-06T17:13:00Z")
Ja das ist mir so weit auch klar. Full ist aber auch so viel ich weiß die einzige Variante wo der belegte Speicherplatz wieder frei wird. Deswegen so ganz darauf verzichten will ich nicht.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [6. Februar 2023 um 17:51 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/11 "2023-02-06T17:51:30Z")
ein normales gibt auch Speicher frei - wenn ‘hinten’ 1 oder mehr Blöcke frei sind. Und wenn in den Blöcken ein bestimmter Prozentsatz ‘frei’ ist kann dieser z.B. bei HOT-Updates genutzt werden. Das ist also per se nicht unbedingt was schlechtes, wenn ein normales Vacuum den Platz nur als wieder verwendbar markiert und nicht physisch an das OS zurück gibt. Ein FULL ist in vielen Anwendungen eh kaum machbar - wenn Du sehr große Tabellen hast und 24\*7 die DB im Einsatz ist.
---
### Author:  [@system](https://www.pg-forum.de/u/system)
#### Post date: [7. April 2023 um 17:51 UTC](https://www.pg-forum.de/t/vacuumdb-habe-ich-einen-denkfehler/12686/12 "2023-04-07T17:51:38Z")
Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.