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

From Michael Paquier
Subject Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Date
Msg-id CAB7nPqSdswVjiPrnxcF8Rfif=ERq3aU7n42wr9Z3m26j=io1sg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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.
--
Michael



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: [HACKERS] Re: [BUGS] BUG #14657: Server process segmentation fault in v10, May10th dev snapshot
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] fix hard-coded index in make_partition_op_expr