From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Schedule pg_repack job with pg_cron |
Date: | 2024-08-08 10:26:22 |
Message-ID: | CANzqJaD-v-ipsWcHY8HV51aWci3SomCf5gN0X2D1nwY3yqL-tg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Aug 8, 2024 at 6:17 AM <shammat(at)gmx(dot)net> wrote:
>
> Ron Johnson schrieb am 07.08.2024 um 21:39:
> > 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.
>
Eh? The whole point of VACUUM is to ensure that the existing allocated
disk space is available for new records?
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.)
--
Death to America, and butter sauce.
Iraq lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | shammat | 2024-08-08 10:59:18 | Re: Schedule pg_repack job with pg_cron |
Previous Message | shammat | 2024-08-08 10:16:53 | Re: Schedule pg_repack job with pg_cron |