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 |
Message-ID: | 1C2CE8A7-7D13-4445-84A1-FAE838C01EA6@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
Nathan
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 |
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. |