Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands |
Дата | |
Msg-id | CAD21AoCyCqVJn6JKgtFo9-cDeN-ALFaj-jZpZqKE7uf5xQi8bA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
|
Список | pgsql-hackers |
On Thu, May 11, 2017 at 11:13 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Thu, May 11, 2017 at 6:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Bossart, Nathan" <bossartn@amazon.com> writes: >>> Currently, VACUUM commands allow you to specify one table or all of the tables in the current database to vacuum. I’verecently found myself wishing I could specify multiple tables in a single VACUUM statement. For example, this wouldbe convenient when there are several large tables in a database and only a few need cleanup for XID purposes. Is thisa 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 agree to report per-table information. Especially In case of one of tables specified failed during vacuuming, I think we should report at least information of tables that is done successfully so far. > >>> I’ve attached my first attempt at introducing this functionality. In the patch, I’ve extended the table_name parameterin the VACUUM grammar to a qualified_name_list. While this fits into the grammar decently well, I suspect thatit 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 > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: