From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | "Zwettler Markus (OIZ)" <Markus(dot)Zwettler(at)zuerich(dot)ch>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: curious vacuum full behavior |
Date: | 2021-02-04 11:42:38 |
Message-ID: | 698d93bea415d0f5ba94cbf3c6d0fe8194b4931d.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2021-02-04 at 10:03 +0000, Zwettler Markus (OIZ) wrote:
> 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
VACUUM (FULL) will re-create the indexes too, and "maintenance_work_mem"
has an impact on index build speed.
But I have no explanation for such a large difference.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2021-02-04 11:56:04 | Re: when is useful min_wal_size? |
Previous Message | Luca Ferrari | 2021-02-04 11:41:30 | when is useful min_wal_size? |