Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Дата
Msg-id CAB7nPqRaZDu1qGsmcgvshmbXxt=7HZ1Lbg7djCfBoZY0Ls_y_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  ("Bossart, Nathan" <bossartn@amazon.com>)
Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Aug 24, 2017 at 12:38 PM, Bossart, Nathan <bossartn@amazon.com> wrote:
> On 8/18/17, 12:56 AM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> According to the docs, VACUUM and ANALYZE "do not support recursing over
> inheritance hierarchies" [1].  However, we need a list of OIDs for
> partitioned tables.  Namely, this piece of code in get_rel_oids(...):
>
>                 if (include_parts)
>                         oid_list = list_concat(oid_list,
>                                                                    find_all_inheritors(relid, NoLock, NULL));
>                 else
>                         oid_list = lappend_oid(oid_list, relid);
>
> Since all of these OIDs should correspond to the same partitioned table,
> it makes sense to me to leave them together instead of breaking out each
> partition into a VacuumRelation.  If we did so, I think we would also need
> to duplicate the va_cols list for each partition.  What do you think?

Robert, Amit and other folks working on extending the existing
partitioning facility would be in better position to answer that, but
I would think that we should have something as flexible as possible,
and storing a list of relation OID in each VacuumRelation makes it
harder to track the uniqueness of relations vacuumed. I agree that the
concept of a partition with multiple parents induces a lot of
problems. But the patch as proposed worries me as it complicates
vacuum() with a double loop: one for each relation vacuumed, and one
inside it with the list of OIDs. Modules calling vacuum() could also
use flexibility, being able to analyze a custom list of columns for
each relation has value as well.

>> - * relid, if not InvalidOid, indicate the relation to process; otherwise,
>> - * the RangeVar is used.  (The latter must always be passed, because it's
>> - * used for error messages.)
>> + * If we intend to process all relations, the 'relations' argument may be
>> + * NIL.
>> This comment actually applies to RelationAndColumns. If the OID is
>> invalid, then RangeVar is used, and should always be set. You are
>> breaking that promise actually for autovacuum. The comment here should
>> say that if relations is NIL all the relations of the database are
>> processes, and for an ANALYZE all the columns are done.
>
> Makes sense, I've tried to make this comment clearer.

+ * relations is a list of VacuumRelations to process.  If it is NIL, all
+ * relations in the database are processed.
Typo here, VacuumRelation is singular.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: psql command \graw
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] Page Scan Mode in Hash Index