Re: [Proposal] Allow users to specify multiple tables in VACUUM commands

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Date: 2017-05-18 05:59:46
Message-ID: CAD21AoD3VvBUMcCyRMR8Dtr=5HakHTdkuQCeGrOFioFYhWMEAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 18, 2017 at 11:01 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, May 18, 2017 at 12:06 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>> I agree with you here, too. I stopped short of allowing customers to explicitly provide per-table options, so the example you 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 ANALYZE option, 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2017-05-18 06:05:15 Re: Hash Functions
Previous Message Jeff Davis 2017-05-18 05:53:01 Re: Hash Functions