On 8/23/17, 11:59 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> 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.
I understand your concern, and I'll look into this for v9. I think the
majority of this change will go into get_rel_oids(...). Like you, I am
also curious to what the partitioning folks think.
> + * relations is a list of VacuumRelations to process. If it is NIL, all
> + * relations in the database are processed.
> Typo here, VacuumRelation is singular.
I'll make this change in v9.
I should also note that the dedupe_relations(...) function needs another
small fix for column lists. Since the lack of a column list means that we
should ANALYZE all columns, a duplicate table name with an empty column
list should effectively null out any other specified columns. For example,
"ANALYZE table (a, b), table;" currently dedupes to the equivalent of
"ANALYZE table (a, b);" when it should dedupe to "ANALYZE table;".
Nathan