On Thu, Aug 24, 2017 at 12:59 AM, 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.
So ... why have a double loop? I mean, you could just expand this out to one entry per relation actually being vacuumed, couldn't you? What happens if you say VACUUM partitioned_table (a), some_partition (b)? + oldcontext = MemoryContextSwitchTo(vac_context); + foreach(lc, relations) + temp_relations = lappend(temp_relations, copyObject(lfirst(lc))); + MemoryContextSwitchTo(oldcontext); + relations = temp_relations; Can't we just copyObject() on the whole list? - ListCell *cur; - Why change this? Generally, declaring a separate variable in an inner scope seems like better style than reusing one that happens to be lying around in the outer scope. + VacuumRelation *relinfo = (VacuumRelation *) lfirst(lc); Could use lfirst_node. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
