Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Date
Msg-id CAD21AoD3VvBUMcCyRMR8Dtr=5HakHTdkuQCeGrOFioFYhWMEAA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, May 18, 2017 at 11:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, May 18, 2017 at 12:06 AM, Bossart, Nathan <bossartn@amazon.com> wrote:
>> I agree with you here, too.  I stopped short of allowing customers to explicitly provide per-table options, so the
exampleyou provided wouldn’t work here.  This is more applicable for something like the following: 
>>
>>         VACUUM (FREEZE, VERBOSE) foo, bar (a);
>>
>> In this case, the FREEZE and VERBOSE options are used for both tables.  However, we have a column list specified for
‘bar’,and the ANALYZE option is implied when we specify a column list.  So when we process ‘bar’, we need to apply the
ANALYZEoption, but we do not need it for ‘foo’.  For now, that is all that this per-table options variable is used for. 
>
> Hm. One argument can be made here: having a column list defined in one
> of the tables implies that ANALYZE is enforced for all the relations
> listed instead of doing that only on the relations listing columns.

It seems to me that it's not good idea to forcibly set ANALYZE in
spite of  ANALYZE option is not specified. One reason is that it would
make us difficult to grep it from such as server log. I think It's
better to use the same vacuum option to the all listed relations.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Hash Functions
Next
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Hash Functions