Alvaro Herrera <alvherre@commandprompt.com> writes:
> Do we need a struct, or can we get away with storing the values directly
> in RelationData? Something like this:
The intention behind having a separate struct was that there could
possibly be different sets of reloptions for different types of
relations, different index AMs, etc. Pushing the fields directly
into Relation puts the kibosh on that permanently, without really
buying much AFAICS.
> One problem is that this enlarges Relation by a fair bit for every
> relation, even those that are never concerned with autovacuum, e.g.
> indexes. I'm not sure how much is this a problem in practice. (It
> could become a problem for people who has thousands of partitions, but
> we don't actually support that.)
Sure we do. Check the archives to find messages from people who are
using thousands of relations right now.
> I have also modified the patch to include the default value for each
> option in the table; to solve the problem of differing fillfactors for
> the different index AMs, I've created separated "kinds" this way:
Right, I was thinking along the same lines. Though this pretty much
destroys any notion that the set of index AMs can be extended without
modifying the core code ... can we adjust it to improve that?
regards, tom lane