Re: Stats for inheritance trees

On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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