Re: Options for more aggressive space reclamation in vacuuming?

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Options for more aggressive space reclamation in vacuuming?
Date: 2023-05-15 07:56:16
Message-ID: 70d586af88aa7365670cd75a826784554c5ce816.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Sun, 2023-05-14 at 14:02 -0700, Wells Oliver wrote:
> I think our use-case here is nothing special: just very large tables that are deleted
> from and re-inserted with some frequency. They store monthly data and exist as partitions.
> As an example, July of 2022 (summer months are peak) had 1,630,558,336 rows. We delete
> from this and insert daily. We rarely get new, relevant data once the month is over.
> The n_dead_tup from pg_stat_all_tables here was over 7m rows, and clearing that out
> gave us back nearly 50GB, and the file size estimate on this partition was ~200 GB.
> These tables get auto-vacuumed but clearly it's not, well, aggressively reclaiming space.

As a rule, normal VACUUM will not reclaim space at all (only if after the run, the last
pages of a tabel are empty). That's why you use range partitioning. Simply drop the
partition that is expired. Ideally, you wouldn't go to the trouble of deleting data at all.

Yours,
Laurenz Albe

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Alvaro Herrera 2023-05-15 11:15:54 Re: how do I capture conflicting rows
Previous Message Ron 2023-05-15 06:42:46 Re: how do I capture conflicting rows