Horton

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

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-09-21T00:58:28Z
Lists: pgsql-hackers 
On Thu, Sep 21, 2017 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Um ... so?  With Nathan's proposed behavior, there are two cases depending
>>> on just when the unexpected schema change happens:
>>> 1. *None* of the work gets done.
>>> 2. The work before the troublesome relation gets done, and the work after
>>> doesn't.
>
>> You may be missing one which is closer to what autovacuum does:
>> 3) Issue a warning for the troublesome relation, and get the work done
>> a maximum.
>
> Well, we could certainly discuss whether the behavior on detecting a
> conflict ought to be "error" or "warning and continue".  But I do not buy
> the value of "it might be one or the other depending on timing".

I definitely agree with that, and I don't want this point to be a
blocker for the proposed patch either. So if you feel that for now the
focus should be on simplicity rather than reliability (my word may be
incorrect here, I mean having a consistent and continuous flow), let's
do so then. We could always change the implemented behavior later on.
-- 
Michael

Commits

  1. Allow multiple tables to be specified in one VACUUM or ANALYZE command.

  2. Give a better error for duplicate entries in VACUUM/ANALYZE column list.

  3. Reject ANALYZE commands during VACUUM FULL or another ANALYZE.