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

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Date: 2017-09-21 16:59:14
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 9/20/17, 7:58 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Sep 21, 2017 at 9:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Alright, here is something that I think is more like what Tom envisioned.
The duplicate column checks have been moved to do_analyze_rel(), and I am
hoping that it is more feasible to back-patch. The main path now
processes each specified relation individually, which admittedly makes the
patch a bit simpler.


Attachment Content-Type Size
0002-vacuum_multiple_tables_v19.patch application/octet-stream 27.3 KB
0001-error_on_duplicate_columns_in_analyze_v6.patch application/octet-stream 3.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2017-09-21 17:01:10 Re: PSA: don't be in a hurry to update to XCode 9.0
Previous Message Claudio Freire 2017-09-21 16:54:01 Re: GUC for cleanup indexes threshold.