Re: Stats for inheritance trees

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Having separate properties for regular attdistinct and inherited
> attdistinct seems fairly worthwhile, but I share your lack of
> enthusiasm for solving the problem by adding more columns to
> pg_attribute. One possibility would be to create a new system catalog
> to hold "non-critical" information on pg_attribute properties - that
> is, anything that isn't likely to be needed to plan and execute
> ordinary queries. attstattarget and attdistinct would certainly
> qualify, and there may be others.

Hmm... offhand it seems like all of these columns would be potential
candidates for pushing out to a secondary catalog:

attstattarget | integer | not null
attdistinct | real | not null
attndims | integer | not null
attislocal | boolean | not null
attinhcount | integer | not null
attacl | aclitem[] |

But even with another ndistinct column, that barely amounts to 2 dozen
bytes saved. Maybe it's worth the trouble in order to shave space from
tuple descriptors, but it seems pretty marginal.

(Actually, it looks to me like we could lose attndims altogether with
little pain ...)

> A second possibility would be to generalize the concept of reloptions
> to apply to columns.

Hm ... the base assumption in the reloptions code is that the user is
free to twiddle all the values. attdistinct and attstattarget might fit
that bill but none of the other stuff would, so we couldn't go very far
in terms of pushing things out of the core attributes. Still there's
some attraction in not having to alter pg_attribute the next time we
think of something like these.

regards, tom lane