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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-12-30 02:12:10|
|Subject: Re: Stats for inheritance trees |
|Previous:||From: Robert Haas||Date: 2009-12-30 01:57:35|
|Subject: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION|