On 8/23/17, 11:59 PM, "Michael Paquier" <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
