Re: [UNVERIFIED SENDER] Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [UNVERIFIED SENDER] Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
Date: 2020-01-24 22:13:44
Message-ID: 01869F4B-130A-4D00-95B1-02D8C8E380FB@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/24/20, 1:32 PM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
>>> I chose to disallow disabling both *_RELATION_CLEANUP options
>>> together, as this would essentially cause the VACUUM command to take
>>> no action.
>>
>> My first reaction is why? Agreed that it is a bit crazy to combine
>> both options, but if you add the argument related to more relation
>> types like toast..
>
> Yes, I suppose we have the same problem if you disable
> MAIN_RELATION_CLEANUP and the relation has no TOAST table. In any
> case, allowing both options to be disabled shouldn't hurt anything.

I've been thinking further in this area, and I'm wondering if it also
makes sense to remove the restriction on ANALYZE with
MAIN_RELATION_CLEANUP disabled. A command like

VACUUM (ANALYZE, MAIN_RELATION_CLEANUP FALSE) test;

could be interpreted as meaning we should vacuum the TOAST table and
analyze the main relation. Since the word "cleanup" is present in the
option name, this might not be too confusing.

Nathan

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-01-24 22:29:11 Re: [HACKERS] kqueue
Previous Message Bossart, Nathan 2020-01-24 21:31:26 Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM