Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "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-02-08 08:46:45
Message-ID: 20210208084645.GR7450@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2021-02-08 08:48:25 Re: Is Recovery actually paused?
Previous Message Mark Rofail 2021-02-08 08:40:32 Re: [HACKERS] GSoC 2017: Foreign Key Arrays