| From: | "Zwettler Markus (OIZ)" <Markus(dot)Zwettler(at)zuerich(dot)ch> |
|---|---|
| To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | curious vacuum full behavior |
| Date: | 2021-02-04 10:03:53 |
| Message-ID: | d9e34b260bfe45b280005f6cdc2814f7@zuerich.ch |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I have 2 identical systems A + B.
B being a clone of A.
The table pg_catalog.pg_largeobject was identical on both systems: 300GB in total size; 100GB bloated.
I did following on A:
? vacuum full pg_catalog.pg_largeobject;
(using the default maintenance_work_mem of 64MB)
It took around 45 minutes and increased the diskspace by around 125% until the vacuum had been finished.
I did following on B:
? set maintenance_work_mem = '256MB';
? vacuum full pg_catalog.pg_largeobject;
This took around 5 minutes. I don't know if the diskspace ever increased.
I was really surprised.
Is there any explanation on this behavior?
Is vacuum full heavily using on-disk sort areas if maintenance_work_mem is too low?
Postgres Version 9.6
Thanks, Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atul Kumar | 2021-02-04 11:26:26 | vacuumdb not letting me connect to db |
| Previous Message | Adith Suresh | 2021-02-04 09:46:02 | PgAdmin 4 GUI not responding |