| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com> |
| Subject: | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM |
| Date: | 2021-01-27 23:16:26 |
| Message-ID: | 930F06F8-3425-48A2-9A2E-11404BAA2341@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/27/21, 11:07 AM, "Justin Pryzby" <pryzby(at)telsasoft(dot)com> wrote:
> This just came up for me:
>
> I have a daily maintenance script which pro-actively vacuums tables: freezing
> historic partitions, vacuuming current tables if the table's relfrozenxid is
> old, and to encourage indexonly scan.
>
> I'm checking the greatest(age(toast,main)) and vacuum the table (and implicitly
> its toast) whenever either is getting old.
>
> But it'd be more ideal if I could independently vacuum the main table if it's
> old, but not the toast table.
Thanks for chiming in.
It looks like we were leaning towards only adding the
TOAST_TABLE_CLEANUP option, which is already implemented internally
with VACOPT_SKIPTOAST. It's already possible to vacuum a TOAST table
directly, so we can probably do without the MAIN_RELATION_CLEANUP
option.
I've attached a new patch that only adds TOAST_TABLE_CLEANUP.
Nathan
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-Add-TOAST_TABLE_CLEANUP-option-to-VACUUM.patch | application/octet-stream | 11.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-01-27 23:19:13 | Re: vacuum_cost_page_miss default value and modern hardware |
| Previous Message | Tatsuro Yamada | 2021-01-27 23:11:08 | Re: Is it useful to record whether plans are generic or custom? |