On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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.
Maybe. I would think that attacl[] would need to be consulted
frequently enough that you'd want to have it around, but maybe not.
> (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.
Yep. It would also lower the barrier to future innovations of that
type, which would be a good thing, IMO. Unfortunately we'd likely
need to continue to support the existing syntax at least for
attstattarget, which is kind of a bummer, but seems managable. I
think we could throw over the syntax for ALTER TABLE ... ADD
STATISTICS DISTINCT since it is an 8.5-ism.
...Robert