On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers