Re: Schedule pg_repack job with pg_cron

From: shammat(at)gmx(dot)net
To: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Schedule pg_repack job with pg_cron
Date: 2024-08-08 10:59:18
Message-ID: 18e91338-db98-47f2-b4e1-5d61a3c1f995@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


Ron Johnson schrieb am 08.08.2024 um 12:26:
>> Part of a properly-maintained system is *regularly* archive/
>> purging (whether that be dropping date-based partitions, or
>> deleting old data from unpartitioned tables or tables partitioned
>> by something other than a date).
>>
>> For example, I gave a list of tables (all intertwined via FK
>> constraints) to the application support people, and they returned
>> the list stating how many weeks or months of data to retain in
>> each table. Every Saturday night a cron job goes through and
>> deletes the old data from, and then "manually" vacuum-analyzes
>> them.
>
>
> If the application will then insert new data after the cleanup,
> Postgres will re-use the free space that the delete "created". So
> depending on the speed of inserts, you might not really gain that
> much.
>
>
> Or did you think that I do a VACUUM FULL on those tables? (No; I
> definitely don't do that, though I /occasionally/ CLUSTER /some/ of
> the tables to make range queries more efficient.)
Sorry, I misread your post and was indeed thinking about VACUUM FULL
as pg_repack is an alternative to that.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Erik Serrano 2024-08-08 14:26:29 Export Query Output to incremental csv file
Previous Message Ron Johnson 2024-08-08 10:26:22 Re: Schedule pg_repack job with pg_cron