>> Hopefully the grouping of tables is not purely related to AV? > > Hmm, good question. I was envisioning it only for autovacuum, but it > hasn't been vetted on pgsql-hackers.
I think we're in danger of inventing a solution in search of a problem here. AIUI, the main reason for table groups would be to define different autovacuum policies for different groups of tables. Right now, that would be pretty stupid, because there are only two possible policies: "yes" and "no". But if the policy is something very complex, then you're not going to want to redefine it for each individual table. Instead, you're going to want to define it once and then point individual tables at it. But you could do that just as well by assigning each policy a name or number and then setting a reloption on the table to refer to that name or number, which would completely avoid the need to invent all-new, non-standard syntax. But if we do decide to invent such a syntax, it's not good enough to say that we should make it general because it might be useful for a purpose other than autovacuum. We should have a pretty specific idea of what sort of purpose that might be. Otherwise, we'll likely find (when the purpose finally arises) that the supposedly-general model we introduced doesn't fit it as well as we thought. But right now, we don't even have ONE use case for the general syntax, let alone two, because the future autovacuum enhancements that would make use of that syntax haven't been designed yet (or at least haven't been discussed here yet). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
