Re: Force re-compression with lz4
От | Florents Tselai |
---|---|
Тема | Re: Force re-compression with lz4 |
Дата | |
Msg-id | 08686473-CF87-4B7B-80D1-71B0FA97C1E5@gmail.com обсуждение исходный текст |
Ответ на | Re: Force re-compression with lz4 (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Force re-compression with lz4
|
Список | pgsql-general |
I did look into VACUUM(full) for it’s PROCESS_TOAST option which makes sense, but the thing is I already had a cron-ed VACUUM(full) which I ended up disabling a while back; exactly because of the double-space requirement. The DB has already a 1TB size and occupying another 600MB would require some hassle. Thus, the external script approach makesmore sense. > On 17 Oct 2021, at 8:28 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > On 10/17/21 10:17, Magnus Hagander wrote: >> On Sun, Oct 17, 2021 at 5:12 PM Florents Tselai <florents.tselai@gmail.com <mailto:florents.tselai@gmail.com>> wrote: > >> Is there a smarter way to do this ? >> It should be enough to VACUUM FULL the table. (but it has to be VACUUM FULL, not a regular vacuum). Or CLUSTER. > > With the proviso that this will require double the existing space, ~670GB, until the operation is completed. > >> -- >> Magnus Hagander >> Me: https://www.hagander.net/ <http://www.hagander.net/> >> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> > > > -- > Adrian Klaver > adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: