| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands | 
| Date: | 2017-05-11 02:13:08 | 
| Message-ID: | CAB7nPqRN3dFNVEH0Jfc5pPg0aC6mKnqa-WG0iTJPMOc6rExfTg@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Thu, May 11, 2017 at 6:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Bossart, Nathan" <bossartn(at)amazon(dot)com> writes:
>> Currently, VACUUM commands allow you to specify one table or all of the tables in the current database to vacuum.  I’ve recently found myself wishing I could specify multiple tables in a single VACUUM statement.  For example, this would be convenient when there are several large tables in a database and only a few need cleanup for XID purposes.  Is this a feature that the community might be interested in?
>
> I'm a bit surprised to realize that we don't allow that, since the
> underlying code certainly can do it.
>
> You realize of course that ANALYZE should grow this capability as well.
Yup. It is just a matter of extending ExecVacuum() to handle a list of
qualified names with a quick look at the grammar as we are talking
only about manual commands. One question I am wondering though is do
we want to have everything happening in the same transaction? I would
say yes to that to simplify the code. I think that VERBOSE should also
report the per-table information, so this can be noisy with many
tables but that's more helpful than gathering all the results.
>> I’ve attached my first attempt at introducing this functionality.  In the patch, I’ve extended the table_name parameter in the VACUUM grammar to a qualified_name_list.  While this fits into the grammar decently well, I suspect that it may be desirable to be able to specify a column list for each table as well (e.g. VACUUM foo (a), bar (b)).
>
> The column list only matters for ANALYZE (or VACUUM ANALYZE).  But yes,
> it should be per-table.
The grammar allows that by the way:
=# VACUUM (full) aa (a);
VACUUM
Perhaps that's an oversight? I don't think it makes much sense.
-- 
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-05-11 02:21:45 | Re: multi-column range partition constraint | 
| Previous Message | Michael Paquier | 2017-05-11 02:05:08 | Re: [PATCH v2] Progress command to monitor progression of long running SQL queries |