On Sat, Aug 26, 2017 at 8:00 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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?
Yes, if I understand that correctly. That's the point I am exactly coming at. My suggestion is to have one VacuumRelation entry per relation vacuumed, even for partitioned tables, and copy the list of columns to each one. > + 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? Yup. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
