Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

Hi,

Thanks for taking a look.

On 7/13/20, 11:02 AM, "Justin Pryzby" <pryzby(at)telsasoft(dot)com> wrote:
> Should bin/vacuumdb support this?

Yes, it should. I've added it in v5 of the patch.

> Should vacuumdb have a way to pass an arbitrary option to the server, instead
> of tacking on options (which are frequently forgotten on the initial commit to
> the backend VACUUM command) ? That has the advantage that vacuumdb could use
> new options even when connecting to a new server version than client. I think
> it would be safe as long as it avoided characters like ')' and ';'. Maybe
> all that's needed is isdigit() || isalpha() || isspace() || c=='_'

I like the idea of allowing users to specify arbitrary options so that
they are not constrained to the options in the version of vacuumdb
they are using. I suspect we will still want to keep the vacuumdb
options updated for consistency and ease-of-use, though. IMO this
deserves its own thread.

> + MAIN_RELATION_CLEANUP [ <replaceable class="parameter">boolean</replaceable> ]
> + TOAST_TABLE_CLEANUP [ <replaceable class="parameter">boolean</replaceable> ]
>
> Maybe should be called TOAST_RELATION_CLEANUP

While using "relation" would be more consistent with the
MAIN_RELATION_CLEANUP option, I initially chose "table" for
consistency with most of the documentation [0]. Thinking further, I
believe this is still the right choice. While the term "relation"
refers to any type of object tracked in pg_class [1], a TOAST table
can only ever be a TOAST table. There are no other special TOAST
relation types (e.g. sequences, materialized views). On the other
hand, it is possible to vacuum other types of "main relations" besides
regular tables (e.g. materialized views), so MAIN_RELATION_CLEANUP
also seems right to me. Thoughts?

Nathan

[0] https://www.postgresql.org/docs/devel/storage-toast.html
[1] https://www.postgresql.org/docs/devel/catalog-pg-class.html