Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
Date
Msg-id 20210208084645.GR7450@telsasoft.com
Whole thread Raw
In response to Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
List pgsql-hackers
On Mon, Feb 08, 2021 at 04:35:19PM +0900, Michael Paquier wrote:
> On Fri, Jan 29, 2021 at 06:43:44PM +0000, Bossart, Nathan wrote:
> > I changed it to PROCESS_TOAST.
> 
> Thanks.  PROCESS_TOAST sounds good to me at the end for the option
> name, so let's just go with that.
> 
> > Done.
> 
> While on it, I could not resist with changing VACOPT_SKIPTOAST to
> VACOPT_PROCESS_TOAST on consistency grounds.  This is used only in
> four places in the code, so that's not invasive.

+1

> @@ -971,6 +998,7 @@ help(const char *progname)
>      printf(_("      --min-mxid-age=MXID_AGE     minimum multixact ID age of tables to vacuum\n"));
>      printf(_("      --min-xid-age=XID_AGE       minimum transaction ID age of tables to vacuum\n"));
>      printf(_("      --no-index-cleanup          don't remove index entries that point to dead tuples\n"));
> +    printf(_("      --no-process-toast          skip the TOAST table associated to the table to vacuum, if
any\n"));

say "associated WITH"

> +      corresponding <literal>TOAST</literal> table for each relation, if one
> +      exists. This is normally the desired behavior and is the default.
> +      Setting this option to false may be useful when it is necessary to only

Maybe it should say "when it is only necessary to"
But what you've written isn't wrong, depending on what you mean.

> @@ -244,6 +244,21 @@ PostgreSQL documentation
> +        Skip the TOAST table associated to the table to vacuum, if any.

associatd with

-- 
Justin



pgsql-hackers by date:

Previous
From: Mark Rofail
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Next
From: Yugo NAGATA
Date:
Subject: Re: Is Recovery actually paused?